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:	Mon, 18 Apr 2016 13:52:27 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	jiri@...nulli.us
Cc:	netdev@...r.kernel.org, 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, dsa@...ulusnetworks.com, f.fainelli@...il.com,
	andrew@...n.ch, vivien.didelot@...oirfairelinux.com, tgraf@...g.ch,
	aduyck@...antis.com
Subject: Re: switchdev fib offload issues

From: Jiri Pirko <jiri@...nulli.us>
Date: Mon, 18 Apr 2016 17:47:57 +0200

> However, if for any reason the switchdev add operation fails, there is an
> abort function called (switchdev_fib_ipv4_abort). This function does two
> things which are both unfortunate in many usecases:
> 1) evicts all fib entries from HW leaving all processing done in kernel
>     - For Spectrum ASIC this means that all traffic running at 100G between
>       all ports is immediately downgraded to ~1-3Gbits
>     - Also this happens silently, user knows nothing about anything went wrong,
>       only forwarding performance suddenly sucks.
> 
> 2) sets net->ipv4.fib_offload_disabled = true
>     - That results in no other fib entry being offloaded, forever,
>       until net is removed and added again, machine reboot is required
>       in case if init_ns
> 
> These 2 issues makes fib offload completely unusable. So I propose
> to start thinking about fixing this.
> 
> I believe that although the current behaviour might be good for default,
> user should be able to change it by setting a different policy. This
> policy will allow to propagate offload error to user.

There were many length discussions about this.

It is extremely hard to load a partial table into the chip and
have it work correctly.  This is because with longest matching
prefix you have to pull out the least specific routing entires
and process them in software.

Also, there is no communication about what makes an entry not be
insertable or not.  So it may be the case that the shorter prefixes
all fit into the table, because those can be compressed and take
up less table space in the chip.

So it's extremely hard to know when "room" is available again.  Room
for what?  One 16-bit prefixed route?  Or room for one arbitrarily
prefixed route?  Which is it?

The user shouldn't need to know anything about this, and I will
be strongly against any design which puts the onus on the user
to configure a table that will fit into the chip.