On 14/08/09 02:10 PM, Eric Cheng wrote:
On Fri, Aug 14, 2009 at 10:58:04AM -0700, Darren Reed wrote:
no, it won't get freed.
I just think it's better to not change the expected behavior of
mpi_fn() because someone passed in a certain flag. I think it's
more consistent with other mac callbacks to let it consume the
packet.
If you're concerned about copying cost, you could do dupmsg() instead
of copymsg() if mpi_no_copy is set.
No. The entire point of the flag is to avoid any duplication,
be it dupmsg or copymsg. They're simply not required with BPF
and do nothing except making things run slower. When using BPF
to capture packets, there should be no need to allocate any
new data structures in the process of capturing the packet
and the only time packet data is copied is when it matches the
filter being applied to the network traffic.
I understand that with this flag the mpi_fn() has read-only semantics.
my worry is that at some point some code (maybe not bpf) may try
to queue the mp instead of completely processing it in the context
of mpi_fn(). this is definitely not allowed because mp could be freed
from the real datapath. the danger with callbacks is you can't tell
how deep they run and you can't guarantee they obey certain retrictions
throughout.
If the mac API's were a committed set of API's to use, then the thing
to do would be to document the behaviour required by the flag so
that it would be clear when it was appropriate to use it.
The way I read your comment, you are arguing for the code to be
slower because someone might write buggy code that uses this flag.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
