Date:	Wed, 18 Mar 2015 22:03:56 -0700
From:	roopa <roopa@...ulusnetworks.com>
To:	John Fastabend <john.fastabend@...il.com>
CC:	John Fastabend <john.r.fastabend@...el.com>,
	Jiri Pirko <jiri@...nulli.us>,
	"Arad, Ronen" <ronen.arad@...el.com>,
	Netdev <netdev@...r.kernel.org>,
	Scott Feldman <sfeldma@...il.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge
 setlink handler

On 3/18/15, 8: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.
thanks for confirming. I will test this again on my side and jiri,..i 
can resubmit this (unless you prefer to).
>
>>
>> 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.

agree and i had raised that concern.
the current policy will not work for us too. But the first attempt was 
trying to keep it simple.
we should be able to change/refine the policy in subsequent patches.
>
> 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.

agreed.
>
> 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.
ack. For us,  we want the kernel FIB to match FIB in HW, but any failure 
to add in HW should fail in kernel too telling Quagga
or any other routing daemon to not add any more routes. With the CPU's 
on the boxes we support, there is no way we can handle fallback to  in 
kernel/software.

Thanks,
Roopa




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists