Date:	Tue, 17 Mar 2015 07:31:18 -0700
From:	John Fastabend <john.r.fastabend@...el.com>
To:	Jiri Pirko <jiri@...nulli.us>,
	John Fastabend <john.fastabend@...il.com>
CC:	"Arad, Ronen" <ronen.arad@...el.com>,
	Netdev <netdev@...r.kernel.org>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	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 03/17/2015 12:00 AM, Jiri Pirko wrote:
> Mon, Mar 16, 2015 at 11:01:30PM CET, john.fastabend@...il.com wrote:
>> [...]
>>
>>>
>>>> If this position is accepted, it would be best to enforce it, possibly in
>>>> rtnl_bridge_setlink().
>>>> My recollection is that others asked to preserve use-cases where SELF flag
>>>> is used for targeting port devices directly without using a bridge device.
>>>
>>> I know it is possible, and it is incorrect and hacky. But it is part of
>>> user api :/ I think we should not abuse this more in the future and
>>> rather make the api correct and use that.
>>>
>>
>> Working my way through my backlog of email sorry for the days delay.
>>
>> Jiri, are you suggesting it is incorrect to configure the hardware L2
>> independent of bridge device? There is absolutely use cases for this.
>>
>> The case being we want the hardware to do L2 learning via fdb and then
>> when flows get 'trapped' into software we want to handle them
>> differently. Possibly send them onto a specific application for logging.
> 
> Yes, but that can be done in transparent way, exposing hw ports, having
> them in bridge/ovs/whatever. Same as we do with rocker.
> 

My point is you don't want a bridge in software at all. So I don't
understand the "transparent" way. In this case you want to configure
the hardware to do l2 bridge and put the ports in some other objects
for simplicity consider a OVS instance in software. In this model
the ports are attached to the software OVS and we do not want to
"transparently" offload any of OVS to hardware.

Also ports can not be in both an OVS instance and bridge instance.

                  +----+----+
                  |   OVS   |      <- netdevs mapped to sw ovs, not offoaded
                  +----+----+
                     |    |
                   sw0p1 sw0p2     <- netdev representing hardware ports
                     |    |
             +----+----+----+---+
             |    L2 hw bridge  |  <- l2 hardware bridge managed via netlink
             +----+----+----+---+

In many cases it doesn't make any sense to fall back to software.
You can't have a 100Gbps links "falling" back onto the kernel datapath.
And in these environments having ports attached to a "transparent" bridge
breaks. Worse the management CPU is usually something light, its not
typically a quad socket top of line CPU where you might have a chance.

Nothing is broke at the moment because we have the "self" flag. I'm
responding to you "incorrect and hacky" comment. Similarly we are
going to need a flag for L3 that puts the rule in hardware or fails.
Just like L2 we can't have L3 being sent into software its not a
viable fallback path in many use cases. And doing it "transparently"
so that the controlling agent is unaware it is offloaded makes it
difficult to manage the system. I think the "transparent" model only
works for smallish devices, home routers and the likes.

Thanks,
.John

>>
>> I'm at a loss around what use "really" running the bridge in software
>> is. There shouldn't be packets traversing the software path and if they
>> are being sent onto software I really can't think of any use case I
>> would want to run them through the software bridge. More likely I want
>> to run OVS or some equivalent controller-based software to forward them
>> "specially" to the correct software/controller/port.
>>
>> My current use case is L2/L3 on the hardware, OVS and applications in
>> software. I don't think this is broken or hacky. This means no bridge
>> in software but programming the L2 bridge in hardware.
>>
>> .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
> 

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