Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge setlink handler

[roopa <roopa@cumulusnetworks.com>]

On 3/18/15, 10:49 PM, Scott Feldman wrote:
> On Wed, Mar 18, 2015 at 8:24 AM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>> [...]
>>> I am not sure how this would be and what other issues you will hit if
>>> you are planning to bypass the kernel and directly go to the switch
>>> driver for all l2 and l3 in the stacked netdevice case. For l3, its
>>> better to use the in-kernel route fib offload mechanism which was
>>> recently submitted by scott feldman.
>>>
>> Why? I saw the patched and liked it but noted that the existing policy
>> wont actually work for real networks. Its a good start. My proposal
>> is to add a flag to l3 to similarly fail to load a rule if it can't
>> be pushed at hardware same as l2.
> RIght, what we have is a start to get the basic plumbing in place.
> Agreed, the current would be inadequate for a real switch that can't
> handle a software fallback.
>
> Maybe the next step is to not flush hw of all routes on failure to add
> the Nth one, but rather just fail the Nth completely (don't install in
> hw or sw and return err to user).  This would keep the switch alive,
> but now moves a decision to the user.  The user must decide what to do
> with the failed Nth route.
I would prefer this. The routing daemon probably already has policies to 
handle routes
  that don't get installed in the FIB (It should not really care if the 
FIB is hardware accelerated or not).

>
> We also added the netlink flag RTNH_F_EXTERNAL to mark routes
> offloaded to hardware, but the marking is only done internally now, by
> the kernel.  What I'm hoping is we can use that same flag in the
> user's netlink msg to work like you describe: if user requests
> RTNH_F_EXTERNAL, and it can't be loaded into hw, don't load into sw.
> Or something like that.  Again, punting the decision on what to do
> next to the user.
yes, however this requires change in userspace (routing daemon) to 
explicitly set this flag.
It definitely can be optional IMO for people who need it (maybe JohnF)
>
> This part of the discussion should probably move to a new thread;
> maybe someone brave can propose a patch to move us to the next level?
>
ack, I will try and get to it this week, unless somebody beats me to it.

Thanks,
Roopa