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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/clearview-discuss/attachments/20090812/cfaa7e6f/attachment.html>
