Date:	Wed, 18 Mar 2015 08:24:55 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	roopa <roopa@...ulusnetworks.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

[...]

>> 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.

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
--
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