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.
With build 80:
#
# dtrace -n 'fbt::copymsgchain:entry{stack();}' -c snoop
dtrace: description 'fbt::copymsgchain:entry' matched 1 probe
Using device e1000g0 (promiscuous mode)
CPU ID FUNCTION:NAME
0 18448 copymsgchain:entry
dls`i_dls_link_rx_func+0xbe
dls`i_dls_link_rx_common_promisc+0x5a
dls`i_dls_link_rx_common+0x170
dls`i_dls_link_rx_promisc+0x20
mac`mac_do_rx+0xb9
mac`mac_rx+0x1b
e1000g`e1000g_intr+0x108
unix`av_dispatch_autovect+0x78
unix`dispatch_hardint+0x2f
unix`switch_sp_and_call+0x13
This is driver dependant. With legacy drivers (eri) that I've
tested with, there is no call to copymsgchain() with snoop.
I first verified this on s10, with nge:
0 15086 copymsgchain:entry
dls`i_dls_link_ether_rx_promisc+0xdf
mac`mac_rx+0x46
nge`nge_receive+0x39
nge`nge_intr_handle+0x138
nge`nge_chip_intr+0x6e
unix`av_dispatch_autovect+0x78
unix`_interrupt+0x1aa
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
