Peter Memishian wrote: > > As an aside, this design does support using STREAMS to capture > > packets quite neatly as it allows complete packets to be queued up > > on the queue, awaiting their turn on the CPU, while packets are > > delivered to sockets simultaneously. But for many packets, the copy > > is made, given to the promiscuous handler and then the original is > > freed because it doesn't have a local destination. > > Could you expand on where you see that? My read of i_dls_link_rx_common() > is that if there's only one matching dls_impl_t (the promiscuous > listener), the fdi_rx logic will skip the copy. >
Ugh, this might depend on the source I was looking at, muxed with the os i looked at behaviour with dtrace. I'll respond to this more meaningfully later. > One question I've long had on this code is why we use copymsg() rather > than dupmsg(). In the STREAMS model, I seem to recall that dupmsg() is used rather than copymsg() (so db_ref > 1) leading to "snoop" recording NAT'd or half-NAT'd packets rather than what comes from the wire unless you do a copymsg() and freemsg() before doing any NAT. I imagine something similar is possible with dls although the implementation is different... Darren _______________________________________________ networking-discuss mailing list [email protected]
