From: Andreas Ferber <aferber@techfak.uni-bielefeld.de>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: Ben Greear <greearb@candelatech.com>,
"David S. Miller" <davem@redhat.com>,
linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
zab@zabbo.net
Subject: Re: Various 802.1Q VLAN driver patches. [try2]
Date: Fri, 1 Mar 2002 21:34:58 +0100 [thread overview]
Message-ID: <20020301213458.A30120@devcon.net> (raw)
In-Reply-To: <20020301.072831.120445660.davem@redhat.com> <3C7FA81A.3070602@candelatech.com> <20020301.081110.76328637.davem@redhat.com> <3C7FAC00.4010402@candelatech.com> <3C7FADBB.3A5B338F@mandrakesoft.com> <20020301174619.A6125@devcon.net> <3C7FD1E3.800A61FD@mandrakesoft.com>
In-Reply-To: <3C7FD1E3.800A61FD@mandrakesoft.com>; from jgarzik@mandrakesoft.com on Fri, Mar 01, 2002 at 02:09:23PM -0500
On Fri, Mar 01, 2002 at 02:09:23PM -0500, Jeff Garzik wrote:
>
> 1) This patch is (like I mentioned earlier) for reference only, not for
> application.
Ack. Although it works like a charme in production here, and I did not
receive any problem reports about it so far. So anyone who needs this
now should apply the patch locally for the moment.
> It is really halfway in between software and hardware VLAN
> support.
Not really. The MTU setting is something which must be done for any
"dumb" card that has no real hardware VLAN support, and the only thing
Cyclone and Tornado cards care about the VlanEtherType is that they
start IP checksumming 4 octets later. They don't care a bit about the
contents of the VLAN tag.
> 2) You don't want to set_8021q_mode if VLAN is not active. It's silly
> to activate it when VLAN is compiled as a module but no one is using
> vlans. That's going to be THE common case, because distros will
> inevitably build the VLAN module with their stock kernel.
Well, this was discussed on the VLAN mailing list. The conclusion
there was that it will not hurt on most cards if it is enabled
unconditionally.
The only situation where it will probably hurt is if you have many
frames exceeding ethernet MTU coming in through your ethernet cable.
Those (up to FDDI size e.g. on 3COM cards without MaxPktSize support)
will not be dropped by the card but instead handed up to the network
stack and be dropped there. Are there any situations (except for
failure cases) where a lot large frames are sent over normal ethernet?
And for the 802.1q recognition of Cyclone and Tornado cards, this only
affects the IP checksumming done by the hardware. As plain IP is never
transmitted in frames with an ethernet type of 0x8100, this also will
not affect normal operation.
Anyway, if you want to enable it only if VLANs are really used on the
card, what about adding a new hook to struct net_device, which can be
used by the 802.1q core code to enable VLAN support on the card as
needed (if supported by the driver)? Or, as this is only a boolean
flag, maybe a generic feature_supported/set_feature hook pair that can
be used for other similar situations in the future?
> 3) 3c59x needs real dev->change_mtu support. This patch provides the
> info needed to do that... but doesn't do that.
Intentionally, as this has nothing to do with VLAN support. The whole
thing about the patch was that you /don't/ have to change the physical
device MTU visible to the network stack. Otherwise the network stack
would start sending oversized frames to the ethernet, which would
render the untagged VLAN useless.
> 4) It uses magic numbers instead of ETH_DATA_LEN and ETH_HLEN
That's what the driver used before ;-)
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - af@devcon.net - www.devcon.net
next prev parent reply other threads:[~2002-03-01 20:35 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-01 15:28 [BETA-0.93] Fourth test release of Tigon3 driver David S. Miller
2002-03-01 16:11 ` Various 802.1Q VLAN driver patches Ben Greear
2002-03-01 16:11 ` David S. Miller
2002-03-01 16:27 ` Various 802.1Q VLAN driver patches. [try2] Ben Greear
2002-03-01 16:30 ` Matti Aarnio
2002-03-01 16:33 ` Randy.Dunlap
2002-03-01 16:42 ` Jeff Garzik
2002-03-01 17:14 ` Various 802.1Q VLAN driver patches. [try3] Ben Greear
2002-03-01 19:24 ` Jeff Garzik
2002-03-01 16:35 ` Various 802.1Q VLAN driver patches. [try2] Jeff Garzik
2002-03-01 16:46 ` Andreas Ferber
2002-03-01 18:45 ` Andrew Morton
2002-03-01 18:50 ` David S. Miller
2002-03-01 19:02 ` Jeff Garzik
2002-03-01 21:00 ` Alan Cox
2002-03-01 20:53 ` Jeff Garzik
2002-03-01 21:10 ` David S. Miller
2002-03-01 19:09 ` Jeff Garzik
2002-03-01 20:34 ` Andreas Ferber [this message]
2002-03-01 20:51 ` Jeff Garzik
2002-03-01 21:19 ` Ben Greear
2002-03-01 21:19 ` David S. Miller
2002-03-01 21:51 ` Andreas Ferber
2002-03-01 16:40 ` David S. Miller
2002-03-01 19:17 ` Various 802.1Q VLAN driver patches Jeff Garzik
2002-03-01 19:44 ` Patrick Schaaf
2002-03-01 19:43 ` Jeff Garzik
2002-03-03 20:16 ` Teodor Iacob
2002-03-01 20:27 ` Donald Becker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020301213458.A30120@devcon.net \
--to=aferber@techfak.uni-bielefeld.de \
--cc=davem@redhat.com \
--cc=greearb@candelatech.com \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=zab@zabbo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox