On Fri, Jan 3, 2014 at 10:00 PM, Chris Luke <chr...@flirble.org> wrote: > Jesse Gross wrote (on Fri 03 Jan, 2014 at 23:48 GMT): > >> On Thu, Jan 2, 2014 at 8:33 PM, Chris Luke <chr...@flirble.org> wrote: >>> >>> Jesse Gross wrote (on Fri 03 Jan, 2014 at 00:27 GMT): >>> >>>> On Thu, Jan 2, 2014 at 6:01 PM, Chris Luke <chr...@flirble.org> wrote: >>>>>> >>>>>> >>>>>> On Jan 2, 2014, at 16:51, Jesse Gross <je...@nicira.com> wrote: >>>>>>> >>>>>>> >>>>>>> On Mon, Dec 23, 2013 at 11:46 PM, Chris Luke <chr...@flirble.org> >>>>>>> wrote: >>>>>>> Jesse Gross wrote (on Tue 24 Dec, 2013 at 03:05 GMT): >>>>>>>> >>>>>>>> >>>>>>>> * This type of concept has come up before and its usually in the >>>>>>>> context of allowing an existing daemon like lldpad to be run on an >>>>>>>> OVS >>>>>>>> port. At a minimum, we would need to make sure that whatever we do >>>>>>>> here is compatible with that and ideally we would be able to >>>>>>>> essentially solve both problems at the same time. If you are >>>>>>>> planning >>>>>>>> on running routing protocol daemons then maybe it is already pretty >>>>>>>> similar. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Exactly. I have lldpd running on my test setup and it appears to work >>>>>>> fine, but I'll dig into it to be sure. >>>>>> >>>>>> >>>>>> >>>>>> Do the packets sent from the daemon go through OVS? It doesn't seem >>>>>> like they would and while this would likely work in many cases, it is >>>>>> odd. >>>>> >>>>> >>>>> >>>>> No, from the daemon they go directly out the port. The case that needs >>>>> OVS involvement is incoming packets. >>>> >>>> >>>> >>>> I believe that it works correctly in most cases but it seems somewhat >>>> weird and asymmetric. Is there anything that we can do about it? >>> >>> >>> >>> I think it's just the nature of it - the datapath only hooks into the >>> receive path of ports. If you wanted DP involvement in the other >>> direction >>> we'd need some hook into host-originated traffic. That would certainly >>> make it feel more symmetric from a user perspective. I can take that on >>> if >>> it's interesting for OVS. >> >> >> I think it's worth looking into at least. It seems like it's probably >> nicer to the user and it might even just fit in logically with >> whatever other changes we need to have a nice hook. > > > The only hook I have found so far for originated traffic uses the AF_PACKET > interface - but that has *all* outgoing traffic for a given port, no > easy indication of local origination and no method to drop or modify the > skb. > > Moreover, since the LLDP daemons all craft their own raw packets and > inject them, using AF_PACKET, into the output queues of target interfaces, > there's no easy way to identify them either. > > The simplest mechanism I can think of to work with both issues is to add a > flag to the skb that says OVS touched the skb. > > We would have two places this is used: > > 1) In __netif_receive_skb_core() it would effectively skip eveythhing until > just after the rx_handler section. There is in fact only a simple loop that > we need, that iterates ptype_base[protocol] and delivers a clone of the skb > to each handler registered there (an alternative mechanic being that we > split that loop into its own helper function and use it directly). > ptype_base > is where, eg, ipv4, ipv6, arp etc register their hooks.
I have a feeling that having a flag in the skb and a test in the main receive path won't be overly well received. There is some random crap in the skb but a lot of it is more historical that might not have gotten in today. I think it order for this to be accepted it would have to have pretty zero impact on the receive path, at least when there are no rx handlers registered. > 2) We'd have to introduce a tx handler mechanism similar to rx_handler that > allows us to signal back to the kernel whether we took the packet or are > handing it back. We'd use the new flag in the skb to understand we already > made a decision on the flow and can pass it on. This hook would be in > dev_hard_start_xmit(), which calls a helper dev_queue_xmit_nit() to do the > AF_PACKET hooking already. The subtle part here is that we are left with > only traffic that was locally originated, however it was originated, and > traffic the kernel has forwarded to the output port from a non OVS-hooked > port. Both cases are ones that we might want OVS control over. > > (In the kernel routed cases, if it came in on an OVS port and was handed > back_to_kernel then it gets the flag, the combination of which implies > "the kernel now has authority over this skb' and we woulkd ignore it on > egress.) I don't know whether it is actually worth the pain to do this. In an ideal world it would clearly be better to have symmetry through OVS but realistically I don't actually have a use case and I suppose that we could always support it later if necessary. I'm also not sure what it would look like to the outside world (for example, what port should it appear to be received on?). _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
