Thread (148 messages) 148 messages, 14 authors, 2014-12-09

Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del

From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: 2014-11-26 03:19:48

On 11/25/14 21:36, Scott Feldman wrote:
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
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.
This is about the policy which states "install as many as you can, dont
worry about failures". In such a case, how do you tell user space back
"oh, btw you know your request #1, #23, and 45 went ok, but nothing else
worked". A simple return code wont work. You could return a code to
say "some worked". At which case user space could dump and find out only
#1, #23 and #45 worked.

Your question below is a different context; Some people may want
the policy where whats in hardware
a) gets to be seen in software and b) allow for destination lookup
failures in hardware to show up in the kernel, refresh the fdb in the
kernel via learning
and c) whats in s.ware gets synced to hardware just because there's
space in the hardware
I dont want any of the above;-> Which would work if we had policy knobs.
Learning, flooding, sync from hardware. Speaking of the last one:
Where is my cookie Scott? I want my cookie.

cheers,
jamal

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help