netdev - Re: ARP resolving for switch drivers

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: <20150227.172649.2209140275022350959.davem@davemloft.net>
Date:	Fri, 27 Feb 2015 17:26:49 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	sfeldma@...il.com
Cc:	roopa@...ulusnetworks.com, netdev@...r.kernel.org,
	shm@...ulusnetworks.com
Subject: Re: ARP resolving for switch drivers

From: Scott Feldman <sfeldma@...il.com>
Date: Thu, 26 Feb 2015 04:03:20 -0800

> I don't have a better label at this time.  "external" for both FDB and
> FIB seems consistent to me since in both cases the kernel's DB (FDB or
> FIB) has entries marked with "external" meaning they exist also in
> some offload device's DB (FDB or FIB), and the device will offload the
> fwd processing from the kernel.

I think allowing explicit control of entry loading into HW is a totally
separate piece of work from initial L3 offload support.

I want to see the most stupid implementation possible at the beginning.

Which means load entries until we cannot any more, and when we reach
that limit flush the entire HW table, stop offloading, and do
everything in software.

If you try to take the next step and allow for fine grained control,
and most intelligent policy on the kernel side of things, we're going
to go back and forth forever.

Get the basic stuff in now, and then we can argue about how to do the
rest meanwhile.
--
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