[ovs-dev] [PATCH for comment only] Allow datapath to pass packets back to the kernel for non-OVS handling

[Jesse Gross]

On Thu, Jan 2, 2014 at 6:01 PM, Chris Luke <chrisy at flirble.org> wrote:
>> On Jan 2, 2014, at 16:51, Jesse Gross <jesse at nicira.com> wrote:
>>> On Mon, Dec 23, 2013 at 11:46 PM, Chris Luke <chrisy at 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?

>>> If you are suggesting a new openflow action, I think that's a broader
>>> conversation point. 'normal' in the OF protocol is imprecise, but it
>>> seems to suggest that the device do whatever is 'normal' for it. OVS
>>> took the approach of being a switch, whereas I want it to behave like a
>>> Linux machine normally would. I saw these as discrete modes of
>>> operation, hence the approach of switching which behaviour is desired.
>>
>> It seems impossibly confusing for OVS to have a switch that makes it
>> operate in a non-OVS mode, including with external configuration, etc.
>> Furthermore, I suspect that the most common use case of this would be
>> to have an LLDP daemon running on a port but OVS doing the traffic
>> switching. In that case, you could actually need to use both types of
>> "normal" simultaneously. I see that you added an additional action in
>> the newest revision of patch but that just means we have multiple very
>> similar mechanisms to configure this.
>
> Yes, I've come to that conclusion independently. I've split the patch up. Will post the series later. Originally I wanted to avoid custom open flow actions, since in my case I am modeling devices that are layer 3 focused. But I don't now think that's as big a deal as I did.
>
> If you feel the switch mode idea is a non-starter then I'll abandon it.

Yeah, I'm pretty strongly opposed to hanging more things onto the
normal action. In OVS there's a history of breaking things out of
normal because they tend to not interact very well with the OpenFlow
pipeline so I'm not eager to mix more things in.