On Fri, Nov 28, 2014 at 2:14 AM, Roopa Prabhu [off-list ref] wrote:

On 11/25/14, 6:36 PM, Scott Feldman wrote:

quoted

On Tue, Nov 25, 2014 at 6:50 AM, Jamal Hadi Salim [off-list ref]
wrote:

quoted

On 11/25/14 11:30, John Fastabend wrote:

quoted

On 11/25/2014 08:18 AM, Jamal Hadi Salim wrote:

quoted

On 11/25/14 11:01, John Fastabend wrote:

quoted

On 11/25/2014 07:38 AM, Jamal Hadi Salim wrote:

quoted

On 11/25/14 05:28, Jiri Pirko wrote:

quoted

Do the work of parsing NDA_VLAN directly in rtnetlink code, pass
simple
u16 vid to drivers from there.

quoted

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

quoted

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.

scott, we do have such usecase today. ie , a fdb entry with both NTF_MASTER
and NTF_SELF set.
And these fdb entries can come from an external controller. The path to get
them to the hw is via the kernel.
The controller can use `bridge fdb add` to add the fdb entries to the kernel
(with NTF_MASTER) and also indicate in the same message to add the fdb entry
to hw (with NTF_SELF). And in this model it is assumed that the kernel fdb
and hw fdb are in sync.

Ya, I understood that from Jamal's explanation.