netdev - Re: switchdev fib offload issues

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 for Android: free password hash cracker in your pocket

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

Message-ID: <57151279.4020806@cumulusnetworks.com>
Date:	Mon, 18 Apr 2016 10:59:37 -0600
From:	David Ahern <dsa@...ulusnetworks.com>
To:	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org
Cc:	davem@...emloft.net, idosch@...lanox.com, eladr@...lanox.com,
	yotamg@...lanox.com, ogerlitz@...lanox.com,
	roopa@...ulusnetworks.com, nikolay@...ulusnetworks.com,
	jhs@...atatu.com, john.fastabend@...il.com, rami.rosen@...el.com,
	gospo@...ulusnetworks.com, stephen@...workplumber.org,
	sfeldma@...il.com, f.fainelli@...il.com, andrew@...n.ch,
	vivien.didelot@...oirfairelinux.com, tgraf@...g.ch,
	aduyck@...antis.com
Subject: Re: switchdev fib offload issues

On 4/18/16 9:47 AM, Jiri Pirko wrote:
> Proposed solutions (ideas):
> 1) per-netns. Add a procfs file:
> 	/proc/sys/net/ipv4/route/fib_offload_error_policy
> 	  with values: "evict" - default, current behaviour
>                         "fail" - propagate offload error to user
> 	The policy value would be stored in struct net.
>
> 2) per-VRF/table
> 	When user creates a VRF master, he specifies a table ID
> 	this VRF is going to use. I propose to extend this so
> 	he can pass a policy ("evict"/"fail").
> 	The policy value would be stored in struct fib_table or
> 	struct fib6_table. The problem is that vfr only saves
> 	table ID, allocates dst but does not actually create
> 	table. That might be created later. But I think this
> 	could be resolved.

Yes, we have a local patch where I do create the table for IPv6. Can do 
that for IPv4 as well. Some other clean ups are needed in this area - 
like the ability to delete a table

>
> 3) per-VFR/master_netdev
> 	In this case, the policy would be also set during
> 	the creation of VFR master. From user perspective,
> 	this looks same as 2)
> 	The policy value would be stored in struct net_vrf (vrf private).

The VRF device is really only used for guiding lookups, not inserting 
routes.

A per table/VRF policy (option 2) seems more appropriate.