[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE4R7bD1Hi+fnKp-Sg6Tn4AcpOu2pwgEYecP8LVA1ioO4FkgRQ@mail.gmail.com>
Date: Tue, 25 Nov 2014 16:36:11 -1000
From: Scott Feldman <sfeldma@...il.com>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: John Fastabend <john.r.fastabend@...el.com>,
Jiri Pirko <jiri@...nulli.us>, Netdev <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
"nhorman@...driver.com" <nhorman@...driver.com>,
Andy Gospodarek <andy@...yhouse.net>,
Thomas Graf <tgraf@...g.ch>,
"dborkman@...hat.com" <dborkman@...hat.com>,
"ogerlitz@...lanox.com" <ogerlitz@...lanox.com>,
"jesse@...ira.com" <jesse@...ira.com>,
"pshelar@...ira.com" <pshelar@...ira.com>,
"azhou@...ira.com" <azhou@...ira.com>,
"ben@...adent.org.uk" <ben@...adent.org.uk>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"vyasevic@...hat.com" <vyasevic@...hat.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Florian Fainelli <f.fainelli@...il.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
John Linville <linville@...driver.com>,
"jasowang@...hat.com" <jasowang@...hat.com>,
"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
"ryazanov.s.a@...il.com" <ryazanov.s.a@...il.com>,
"buytenh@...tstofly.org" <buytenh@...tstofly.org>,
Aviad Raveh <aviadr@...lanox.com>,
"nbd@...nwrt.org" <nbd@...nwrt.org>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Neil Jerram <Neil.Jerram@...aswitch.com>,
"ronye@...lanox.com" <ronye@...lanox.com>,
"simon.horman@...ronome.com" <simon.horman@...ronome.com>,
"alexander.h.duyck@...hat.com" <alexander.h.duyck@...hat.com>,
"Ronciak, John" <john.ronciak@...el.com>,
"mleitner@...hat.com" <mleitner@...hat.com>,
Shrijeet Mukherjee <shrijeet@...il.com>,
Andy Gospodarek <gospo@...ulusnetworks.com>,
Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
On Tue, Nov 25, 2014 at 6:50 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> On 11/25/14 11:30, John Fastabend wrote:
>>
>> On 11/25/2014 08:18 AM, Jamal Hadi Salim wrote:
>>>
>>> On 11/25/14 11:01, John Fastabend wrote:
>>>>
>>>> On 11/25/2014 07:38 AM, Jamal Hadi Salim wrote:
>>>>>
>>>>> On 11/25/14 05:28, Jiri Pirko wrote:
>>>>>>
>>>>>> Do the work of parsing NDA_VLAN directly in rtnetlink code, pass
>>>>>> simple
>>>>>> u16 vid to drivers from there.
>>>>>>
>>>>>
>
>
>> Actually (after having some coffee) this becomes much more useful
>> if you return which items failed. Then you can slam the hardware
>> with your 100 entries, probably a lot more then that, and come back
>> later and clean it up.
>>
>
> Yes, that is the general use case.
> Unfortunately at the moment we only return codes on a netlink set
> direction - but would be a beauty if we could return what succeeded
> and didnt in some form of vector.
> Note: all is not lost because you can always do a get afterwards and
> find what is missing if you got a return code of "partial success".
> Just a little less efficient..
>
>
>> We return a bitmask of which operations were successful. So if SW fails
>> we have both bits cleared and we abort. When SW is successful we set the
>> SW bit and try to program the HW. If its sucessful we set the HW bit if
>> its not we abort with an err. Converting this to (1) is not much work
>> just skip the abort.
>>
>
> Ok, guess i am gonna have to go stare at the code some more.
> I thought we returned one of the error codes?
> A bitmask would work for a single entry - because you have two
> options add to h/ware and/or s/ware. So response is easy to encode.
> But if i have 1000 and they are sparsely populated (think an indexed
> table and i have indices 1, 23, 45, etc), then a bitmask would be
> hard to use.
I'm confused by this discussion. Do I have this right: You want to
send 1000 RTM_NEWNEIGHs to PF_BRIDGE with both NTF_MASTER and NTF_SELF
set such that 1000 new FBD entries are installed in both (SW) the
bridge's FDB and (HW) the port driver's FDB. My first confusion is
why do you want these FBD entries in bridge's FDB? We're offloading
the switching to HW so HW should be handling fwd plane. If ctrl pkt
make it to SW, it can learn those FDB entries; no need for manual
install of FDB entry in SW. It seems to me you only want to use
NTF_SELF to install the FDB entry in HW using the port driver. And an
error code is returned for that install. Since there is only one
target (NTF_SELF) there is no need for bitmask return.
> cheers,
> jamal
--
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