netdev - Re: [RFC PATCH net-next] switchdev: don't abort hardware ipv4 fib offload on failure to program fib entry in hardware

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]

Message-ID: <5546F7F0.6010404@cumulusnetworks.com>
Date:	Sun, 03 May 2015 21:39:12 -0700
From:	roopa <roopa@...ulusnetworks.com>
To:	"Rosen, Rami" <rami.rosen@...el.com>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	"sfeldma@...il.com" <sfeldma@...il.com>,
	"john.fastabend@...il.com" <john.fastabend@...il.com>,
	"jiri@...nulli.us" <jiri@...nulli.us>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next] switchdev: don't abort hardware ipv4 fib
 offload on failure to program fib entry in hardware

On 5/3/15, 2:28 AM, Rosen, Rami wrote:
> Hi,
> Removing the netdev_switch_fib_ipv4_abort() when there is an error in programming fib entry in hardware seems reasonable to me. I Just want to note that this is not only a matter of CPU strength; even if the switches' CPUs were powerful enough to do routing in software, still doing so seems not a good option, as routing is implemented in different ways by different switch vendors.
>
>
agree,

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