netdev - Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <550AD635.8040502@intel.com>
Date:	Thu, 19 Mar 2015 06:59:17 -0700
From:	John Fastabend <john.r.fastabend@...el.com>
To:	roopa <roopa@...ulusnetworks.com>,
	Scott Feldman <sfeldma@...il.com>
CC:	John Fastabend <john.fastabend@...il.com>,
	Jiri Pirko <jiri@...nulli.us>,
	"Arad, Ronen" <ronen.arad@...el.com>,
	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge
 setlink handler

On 03/19/2015 06:29 AM, roopa wrote:
> On 3/18/15, 10:49 PM, Scott Feldman wrote:
>> On Wed, Mar 18, 2015 at 8:24 AM, John Fastabend
>> <john.fastabend@...il.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).
> 

+1 this works for me as well.

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

Yes it would be helpful for some software but I think getting the above
case working first seems to be the right approach to me.

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

> Thanks,
> Roopa
> 
> 

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