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.