netdev - Re: 802.1Q support?

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: <20090119090713.GB17124@xi.wantstofly.org>
Date:	Mon, 19 Jan 2009 10:07:13 +0100
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	Robin Getz <rgetz@...ckfin.uclinux.org>
Cc:	Florian Fainelli <florian@...nwrt.org>, netdev@...r.kernel.org
Subject: Re: 802.1Q support?

On Tue, Jan 13, 2009 at 11:54:07AM -0500, Robin Getz wrote:

> > > Great - That looks like the way to go -- is there any plan in sending this
> > > to mainline?
> > 
> > Yes we will definitively submit it for mainline inclusion, Felix, who wrote 
> > the swconfig stuff will probably want to clean it up a bit and/or add 
> > features.
> > 
> > Lennert Buytenhek also proposed a Distributed Switch Architecture which is 
> > worth looking at, though it does not cover more "classical" switches 
> > connection over GPIO, SPI or special PHY address.
> 
> Hmmm ... 
> https://kerneltrap.org/mailarchive/linux-netdev/2008/9/25/3411164/thread
> 
> > The switch driver presents each port on the switch as a separate
> > network interface to Linux, polls the switch to maintain software
> > link state of those ports, forwards MII management interface
> > accesses to those network interfaces (e.g. as done by ethtool) to
> > the switch, and exposes the switch's hardware statistics counters
> > via the appropriate Linux kernel interfaces.
> 
> This exposes eth[n] for every port - and these are managed by the standard 
> userspace tools? 

Yep.  And the idea is that the HW switch chip will just follow the Linux
networking stack configuration, a la (ugly hack patch, but it shows the
idea):

	http://marc.info/?l=linux-netdev&m=123115178119072&w=2


> That seems like it would be more intuitive for end users -- wouldn't it?

Requiring special config tools is backwards, IMHO -- there should be no
difference for the end user between whether there is a hardware offload
present or not.
--
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