>if you have a queue, it will fill up.  if it's full, the kernel can't
>queue more packets for you.  don't get me wrong...bpf also drops
>packets if some queue is full.  but the queue does fill up.

Exactly. my point is, this aspect is a wash.

>PF_PACKET strikes me as something that is just "different" from pbf,
>and probably possessing of its own quirks and foibles.  certainly just
>opening one and reading from it would supply you with far too much
>data and you'd need some sort of filtration mechanism.

Exactly.  Just open a PF_PACKET socket and read *everything* from it,
and your multihomed host loses even more quickly than a single-homed
host.


>not really, since PF_PACKET, as i understand it, provides one
>interface to all network traffic, whereas with bpf, you'd have to bind
>one to each interface you on which you wished to listen.  your code
>would increase in compexity also, since you'd have to do polled io on
>each bpf descriptor to read all the traffic in, instead of just
>reading in the next packet.

See above.  And if it wasnt already bad enough, consider the case of
needing to *send* packets -- ala DHCP, where you want to send a
response out the same interface on which you received a packet.
Either you reinvent SO_BINDTODEVICE; which puts you down the route of
one packet per interface anyway.  (Ask Elliot Poger; he may remember
the conversations we had about this.)

Andrew, please dont take this the wrong way, but have you ever
tried to use this monstrosity?