Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge setlink handler

[John Fastabend <john.fastabend@gmail.com>]

On 03/18/2015 08:24 AM, John Fastabend wrote:
> [...]
>
>>> So what about a vlan device?
>> Our main focus has always been devices which use the in-kernel bridge
>> driver. We have been testing this with mainly vlan
>> filtering bridge. But yes, vlan and vxlan devices will need to be
>> supported in the stacked netdevice case.
>> And that's why the initial proposal was to transparently traverse the
>> stacked netdevs and we are trying to bring that back in this thread.
>>
>>> In this case the software viewpoint is different then the hardware
>>> viewpoint so is it correct to pass the configuration down like this?
>>
>> We just want bridge port config passed down to the switch driver.
>>
>
> Sure thought about it some more and I can't see any cases that break.
> But it is a change in the model from the normal software case.
>
>>> Also what if the bond device
>>> is a LAG, is it correct to passthrough like this?
>> hmm...I don't think it matters. We are just trying to get to the switch
>> driver.
>
> Came to the same conclusion, it doesn't seem to matter it is different
> though.
>
>>>
>>> Thanks for the clarification I guess I need to work through some
>>> examples to convince myself
>>> this works. I'm guessing you (or someone) already did this and I'm
>>> just late to the game.
>>>
>> For cases where we use the in-kernel bridge driver, yes it is tested for
>> passing down bridge port attributes that is
>> different than the in-kernel bridge attributes (example learning).
>
> Yep, I've tested it here as well this is good.
>
>>
>> I am not sure how this would be and what other issues you will hit if
>> you are planning to bypass the kernel and directly go to the switch
>> driver for all l2 and l3 in the stacked netdevice case. For l3, its
>> better to use the in-kernel route fib offload mechanism which was
>> recently submitted by scott feldman.
>>
>
> Why? I saw the patched and liked it but noted that the existing policy
> wont actually work for real networks. Its a good start. My proposal
> is to add a flag to l3 to similarly fail to load a rule if it can't
> be pushed at hardware same as l2.
>

Or minimally don't flush the l3 table on an overrun and generate
a notification that the flow has _only_ been added to software. Then
my software agent can handle the exception case in some more intelligent
way if it wants to and I haven't dropped everything into software.

The best way to proceed is probably to write up a patch with a proposal
and get feedback.

> I'm getting off the topic of this thread I guess but I'm not
> bypassing anything IMO. I want to configure the hardware datapath and I
> want to configure the software datapath. For devices with 10, 40,
> 100Gbps links dropping traffic into the software datapath is not a
> viable option in many cases. Traffic will degrade, packets will be
> dropped and with 100's or 1000's of these switches managing a network
> that some times jumps into software or worse on a single path through
> the network might be in software on one hop and in hardware in the next
> is not manageable.
>
> When a packet hits the software datapath it is the exception case I want
> to handle it as an exception. It also got into the software datapath
> because I had a "trap" action in hardware to send it up to software. So
> having the software/hardware datapaths mirror each other isn't really
> useful at least on the devices I work on. For small home routers and
> other types of systems it makes some sense. Perhaps you can even manage
> 10Gpbs ports like this if you are careful but I really don't see how you
> throw a set of 100Gbps links up to kernel datapath running on a
> smallish CPU.
>
> .John
>


-- 
John Fastabend         Intel Corporation