Peter Memishian writes: > > > 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. > > One question I've long had on this code is why we use copymsg() rather > than dupmsg().
I _think_ the original rationale was that, since we're just going to do a copymsg() in ip_input->ip_fix_dbref anyway, we might as well skip the wasteful allocation/free of an mblk_t (merely to tell IP, "here; you do the copy") and skip right to the data copy that's going to happen anyway. It might be nice if IP were a little more graceful in handling ref'd dblks, but that probably would be a lot more complicated. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
