On 12/08/09 06:20 PM, Sebastien Roy wrote:
On Wed, 2009-08-12 at 14:58 -0700, Darren Reed wrote:
* 1168: What's the purpose of this addition? This function only gets
called for ipnet_t streams that are on the /dev/lo0 device.
Discuss.
ipnet_loaccept() is used twice: once in ipnet_open() and once in
ipnet_promisc_add().
I don't follow. ipnet_acceptfn should only be set to ipnet_loaccept()
if /dev/lo0 is opened, and in no other case. Therefore the check you
added in the function itself: "if (getminor(ipnet->ipnet_if->if_dev) ==
IPNET_MINOR_LO)" is redundant. If ipnet_loaccept() is getting called
when it shouldn't be, then something else is wrong.
So lets examine ipnet_accept vs ipnet_loaccept for the purpose of
lo0 packets going through ipnet, into BPF, in a local zone with a
shared stack.
If we set ipnet_acceptfn to ipnet_accept for lo0 packets that are
going to end up in BPF:
- the IP address of the packet isn't important, so what address type
it is does not matter, thus calls to ipnet_get_addrtype() are not
required;
The address is important. A consumer of an ipnet device receives
packets if they contain an IP address assigned to that interface (this
is described in the IP Observability PSARC case). That's the
distinction between /dev/lo0 and /dev/ipnet/lo0 (and thus the difference
between ipnet_accept() and ipnet_loaccept()).
- the lo0 interface has no special behaviour for promiscuous mode,
so that flag and the SAP one are meaningless;
- thus there's lots of code in that function that gets executed for
seemingly no reason.
ipnet_accept() implements the semantics of _all_ ipnet observability
nodes including /dev/ipnet/lo0. ipnet_loaccept() only implements the
semantics of /dev/lo0 (which are deliberately different as described in
the PSARC case). If you feel that ipnet_accept() does not perform well
enough for the special case of /dev/ipnet/lo0 in a shared stack zone,
then the answer isn't to break its semantic by using ipnet_loaccept(),
but rather to address its performance issues (if indeed there are any).
The goal of using BPF in a local zone with a shared stack is to
see all of the traffic in that zone which is associated with the
lo0 "interface". The ipnet_loaccept function provides a filter
that does exactly that - except for the filter on the hook type.
I suppose i could add an ipnet_bpf_loaccept but it would be
a carbon copy of ipnet_loaccept with that check removed.
I think what I'm saying is that BPF on lo0 in a zone has the
same semantics as /dev/lo0 and not /dev/ipnet/lo0.
I don't understand. I thought that there were different "levels" of
observability for BPF, where if one enabled DLT_IPNET, one would get the
ipnet semantics (/dev/ipnet/* for any device). I would then assume that
for "lo0", if one does not use DLT_IPNET, then one gets the /dev/lo0
semantics, but if one enables DLT_IPNET, one gets /dev/ipnet/lo0
semantics.
Ah, I see what you're driving at.
So I suppose the task then is to implement both DLT_NULL and
DLT_IPNET for lo0 as opposed to just DLT_IPNET.
I hadn't considered that...
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
