Subject: Re: [patch net-next v2 10/10] rocker: implement L2 bridge offloading

From: Roopa Prabhu <[email-masked]>
Date: Mon, 10 Nov 2014 10:35:59 -0800

On 11/10/14, 9:36 AM, Scott Feldman wrote:
> On Mon, Nov 10, 2014 at 6:12 AM, Roopa Prabhu <[email-masked]> wrote:
>> On 11/10/14, 4:27 AM, Jamal Hadi Salim wrote:
>>> On 11/10/14 03:46, Scott Feldman wrote:
>>>
>>>> IFLA_BRPORT_LEARNING is u8 attr and we're only using lower bit to turn
>>>> learning on/off.  Maybe we can use another bit to indicate learning to
>>>> be done in sw or hw.  I don't think adding another bit would break
>>>> existing iproute2.
>>>>
>>>> LEARNING_ENABLED    (1 << 0)
>>>> LEARNING_HW              (1 << 1)
>>>>
>>>> Would this work?
>>>>
>>> Yes to making it a bit. But:
>>> This is not *learning*. You are doing a *sync*.
>>> Those are two different things.
>>>
>>> Learning on/off exists today. It signals to the L2 whether you
>>> should learn or not.
>>> I like the way fdb_add/del work with a flag which says
>>> it is the software and/or offloaded version. Please keep that
>>> semantic.
>>> What you are doing above is letting the hardware learn then
>>> syncing to software. You need a different flag there. something
>>> like:
>>>
>>> SYNC_HW_FDB (1<<1)
>>>
>> And in any case, It seems like this policy should be per bridge or per
>> switch chip...or per fdb..
>> entry (like the original fdb_add/del) and not a "port" flag.. ?
> Per-port gives more flexibility, and it looks like we can extend
> existing IFLA_BRPORT_LEARNING without much trouble.
>
> I didn't follow the fdb_add/del comment?  Isn't an fdb entry
> port-specific by nature?  fdb entry = {port, mac, vlan} tuple.
yes it is, But if i remember correctly, the api (ndo op) could indicate 
offload to hw (or nic in this case)
by giving 'self'. And in those cases the netdev nic port represents the 
switch.
  (Will be nice to check and confirm this though).