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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 19 Apr 2016 09:02:03 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	David Ahern <dsa@...ulusnetworks.com>
Cc:	netdev@...r.kernel.org, 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

Mon, Apr 18, 2016 at 06:59:37PM CEST, dsa@...ulusnetworks.com wrote:
>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.

Right. Option 2 also seems better to me. Thanks.