[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-vlan
Subject: [VLAN] help
From: "A.Sreenivasulu Reddy" <asreddy () qpackets ! com>
Date: 2001-10-24 19:37:41
[Download RAW message or body]
----- Original Message -----
From: <vlan-request@Scry.WANfear.com>
To: <vlan@Scry.WANfear.com>
Sent: Wednesday, October 24, 2001 12:01 PM
Subject: VLAN digest, Vol 1 #428 - 6 msgs
> Send VLAN mailing list submissions to
> vlan@Scry.WANfear.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.WANfear.com/mailman/listinfo/vlan
> or, via email, send a message with subject or body 'help' to
> vlan-request@Scry.WANfear.com
>
> You can reach the person managing the list at
> vlan-admin@Scry.WANfear.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of VLAN digest..."
>
>
> Today's Topics:
>
> 1. building kernel modules (John Newbigin)
> 2. Re: [RFC] Re: [VLAN] 3C905C-TX and kernel 2.4.12 wont budge (Ard van
Breemen)
> 3. Changing vlan's mac, why go promisc (Ard van Breemen)
> 4. Re: Changing vlan's mac, why go promisc (Ben Greear)
> 5. Re: [RFC] Re: [VLAN] 3C905C-TX and kernel 2.4.12 wont budge (Andreas
Ferber)
> 6. Re: [RFC] Re: [VLAN] 3C905C-TX and kernel 2.4.12 wont budge (Ben
Greear)
>
> --__--__--
>
> Message: 1
> Date: Wed, 24 Oct 2001 18:05:16 +1000
> From: John Newbigin <jn@it.swin.edu.au>
> Organization: Swinburne University of Technology
> To: vlan@Scry.WANfear.com
> Subject: [VLAN] building kernel modules
> Reply-To: vlan@Scry.WANfear.com
>
> I can't remember if it was on this list that someone asked how to create
> a kernel module from multiple .o files. If it was then I beleive this
> is
> the answer (from http://www.linuxdoc.org/LDP/lkmpg/node13.html)
>
> ld -m elf_i386 -r -o hello.o start.o stop.o
>
> John.
>
> --
> Information Technology Innovation Group
> Swinburne University. Melbourne, Australia
> http://uranus.it.swin.edu.au/~jn
>
> --__--__--
>
> Message: 2
> From: Ard van Breemen <ard@telegraafnet.nl>
> Date: Wed, 24 Oct 2001 12:48:35 +0200
> To: vlan@Scry.WANfear.com
> Cc: Pauline Middelink <middelink@polyware.nl>,
> Maciej Bogucki <bogucki@3dart.com>, Ben Greear
<greear@wanfear.com>
> Subject: Re: [RFC] Re: [VLAN] 3C905C-TX and kernel 2.4.12 wont budge
> Reply-To: vlan@Scry.WANfear.com
>
> On Tue, Oct 23, 2001 at 11:36:57PM +0200, Andreas Ferber wrote:
> > 2) add a set_8021q_receive() callback to struct net_device which
> > enables/disables tagged frame receives on a physical interface,
> > plus patch drivers to provide an appropriate callback function
> >
> > Upsides: everything works automatically, 802.1q receives are
> > automatically enabled/disabled when adding/removing VLANs
> > Downsides: will most probably only be included into kernel together
> > with the VLAN patch, until then the driver patches must
> > be maintained separate from the upstream drivers
> Could you try to have a look at NICE.
> Personally I am in favor of having extra callback, or other vlan
> supporting stuff in the kernel.
> But if you go that way, you have to do it right (my opinion).
> I'd rather see some abstracted functions still called through dirty and
> ugly hacks (ioctls) until we can settle through experience on a good api.
>
> For now I guess it is important for vlan to get into the kernel as it
> is now. More people will look at it, because they will see this nifty
> feature in their kernel-config. And drivers will follow then.
> > 3) a combination of the two above: for the moment just add a module
> > option to NIC drivers and try to get that into upstream kernel. In
> > parallel add the set_8021q_receive() framework (without the driver
> > parts) to the VLAN patch (and keep around driver patches that
> > actually use that framework, to test it ;-). When the VLAN patch is
> > finally accepted into upstream kernel, it will require only little
> > work to migrate the module options to the set_8021q_receive()
> > framework, because the hardware setup code etc. is already there.
> I have done this for intel's e100 driver:
> It tests if VLAN.* is defined and then put's the driver into long_rx mode.
> It does however understand the 8021q tag somehow, so hardware checksumming
> works.
> > Personally I vote for option 3. I'm interested in other opinions on
> > the subject (especially Bens ;-), if there are no major objections I
> > will start a first try on implementing this (for the 3c59x driver ;-)
> > soon.
>
> BTW:
> At this moment I am considering another kernel-patch for the debian
> vlan package:
> I want to patch all those network drivers to get it to work with vlans.
> I guess it is rather important that the network drivers should work.
> I do not like to get ton's of bugreports :(.
> So any info on driver patches are welcome :)...
> I plan to compile it into a list
> --
> <ard@telegraafnet.nl> Telegraaf Elektronische Media http://wwwijzer.nl
> http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html
> Let your government know you value your freedom. Sign the petition:
> http://petition.eurolinux.org/
>
> --__--__--
>
> Message: 3
> From: Ard van Breemen <ard@telegraafnet.nl>
> Date: Wed, 24 Oct 2001 13:06:47 +0200
> To: vlan@Scry.WANfear.com
> Subject: [VLAN] Changing vlan's mac, why go promisc
> Reply-To: vlan@Scry.WANfear.com
>
> Hi,
> I know this has been discussed a while ago. But now I want to discuss
> it again :).
>
> If I change the mac adress of a vlan, the physical interface goes promisc.
> Isn't it possible just to add the mac of the vlan device to the multicast
> list? As far as I know, the hardware really does not check the difference
> between a multicast address or a normal mac.
> The good side is that it is changeable on the fly...
> --
> <ard@telegraafnet.nl> Telegraaf Elektronische Media http://wwwijzer.nl
> http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html
> Let your government know you value your freedom. Sign the petition:
> http://petition.eurolinux.org/
>
> --__--__--
>
> Message: 4
> Date: Wed, 24 Oct 2001 08:08:49 -0700
> From: Ben Greear <greearb@candelatech.com>
> Organization: Candela Technologies
> To: vlan@Scry.WANfear.com
> Subject: Re: [VLAN] Changing vlan's mac, why go promisc
> Reply-To: vlan@Scry.WANfear.com
>
> Ard van Breemen wrote:
> >
> > Hi,
> > I know this has been discussed a while ago. But now I want to discuss
> > it again :).
> >
> > If I change the mac adress of a vlan, the physical interface goes
promisc.
> > Isn't it possible just to add the mac of the vlan device to the
multicast
> > list? As far as I know, the hardware really does not check the
difference
> > between a multicast address or a normal mac.
> > The good side is that it is changeable on the fly...
>
> I think the main problem was that I didn't trust multicast to work
> so I went with the first thing I got working :)
>
> It shouldn't be too hard to change the code to add a MC address
> instead of going promisc... I can help test that patch here
> if you want to make one....
>
> As for driver tweaks, there are many in the mailing list, and I've
> condensed a few into a section in the HOWTO. Not sure how up-to-date
> the patches are though...
>
> Ben
>
> --
> Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com>
> President of Candela Technologies Inc http://www.candelatech.com
> ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
>
> --__--__--
>
> Message: 5
> Date: Wed, 24 Oct 2001 19:23:06 +0200
> From: Andreas Ferber <af@cooper.subway.devcon.net>
> To: vlan@Scry.WANfear.com
> Cc: Pauline Middelink <middelink@polyware.nl>,
> Maciej Bogucki <bogucki@3dart.com>, Ben Greear
<greear@wanfear.com>
> Subject: Re: [RFC] Re: [VLAN] 3C905C-TX and kernel 2.4.12 wont budge
> Organization: dev/consulting GmbH
> Reply-To: vlan@Scry.WANfear.com
>
> On Tue, Oct 23, 2001 at 02:57:55PM -0700, Ben Greear wrote:
> > >
> > > 1) submit patches to the NIC driver maintainers that add a module
> > > option to enable 802.1q tagged frame receives (this option does not
> > > hurt in a kernel without VLAN support).
> > >
> > > Upsides: could possibly be included in kernel independent of the
> > > generic VLAN support
> > > Downsides: the user has to give the appropriate options manually
> > I was hoping that changes like this could be always-on, and that they
> > would be backwards compatible with non-VLAN packets. Is there ever
> > a case where enabling VLANs to work on a particular NIC breaks it for
> > regular traffic? (I certainly hope there isn't, as it will break
> > the ability to send/rcv un-tagged packets on an interface!!)
>
> I don't know of any cards where always enabling it will actually break
> anything, but I'm a little bit concerned that it will probably hurt
> performance on some cards. For example with 3Com 3C905 NICs (without
> B/C) the only possibility is to allow large packet receives, which
> will pass every oversized frame up to ~4500 bytes to the driver,
> though I don't have any numbers if this is a problem in reality.
> Another thing is that eventually some drivers will have to disable HW
> checksumming to receive tagged frames, and this will have some real
> potential to hurt performance.
>
> But anyway, if we leave it completely up to the driver maintainers, it
> is their own choice if they add a module option or just
> unconditionally enable tagged frame receives. They are probably the
> ones who know best what is the best for their hardware ;-)
>
> > I really want to keep the VLAN patch as simple and non-intrusive as
possible
> > untill we can get it into the kernel (I fear that more complexity will
slow
> > down it's inclusion.)
>
> OK with me. So for the moment I will stick to solution 1, and start
> with writing a new patch for the 3c59x.c driver (and trying to get
> that into upstream kernel). If we later come to another solution, the
> adaption will be quite simple as stated before.
>
> > I also do NOT want to have driver patches in the
> > VLAN patch if possible,
>
> ACK, my thoughts were to have some sort of "driver patch repository"
> where you can pick your needed driver patches, close to the current
> situation where some patches are included in the HOWTO. For example,
> from spec reading I think my updated 3c59x patch will be a little bit
> longer than just two changed lines (mainly because the necessary
> hardware features to receive tagged frames changed quite a bit during
> the course of the NICs supported by this driver...), so it will
> probably be unsuitable to cut and paste it from the HOWTO.
>
> Andreas
> --
> Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
> ---------------------------------------------------------
> +49 521 1365800 - af@devcon.net - www.devcon.net
>
> --__--__--
>
> Message: 6
> Date: Wed, 24 Oct 2001 10:37:31 -0700
> From: Ben Greear <greearb@candelatech.com>
> Organization: Candela Technologies
> To: Andreas Ferber <af@cooper.subway.devcon.net>
> CC: vlan@Scry.WANfear.com, Pauline Middelink <middelink@polyware.nl>,
> Maciej Bogucki <bogucki@3dart.com>, Ben Greear
<greear@wanfear.com>
> Subject: Re: [RFC] Re: [VLAN] 3C905C-TX and kernel 2.4.12 wont budge
> Reply-To: vlan@Scry.WANfear.com
>
> Andreas Ferber wrote:
> >
> > On Tue, Oct 23, 2001 at 02:57:55PM -0700, Ben Greear wrote:
> > > >
> > > > 1) submit patches to the NIC driver maintainers that add a module
> > > > option to enable 802.1q tagged frame receives (this option does
not
> > > > hurt in a kernel without VLAN support).
> > > >
> > > > Upsides: could possibly be included in kernel independent of the
> > > > generic VLAN support
> > > > Downsides: the user has to give the appropriate options manually
> > > I was hoping that changes like this could be always-on, and that they
> > > would be backwards compatible with non-VLAN packets. Is there ever
> > > a case where enabling VLANs to work on a particular NIC breaks it for
> > > regular traffic? (I certainly hope there isn't, as it will break
> > > the ability to send/rcv un-tagged packets on an interface!!)
> >
> > I don't know of any cards where always enabling it will actually break
> > anything, but I'm a little bit concerned that it will probably hurt
> > performance on some cards. For example with 3Com 3C905 NICs (without
> > B/C) the only possibility is to allow large packet receives, which
> > will pass every oversized frame up to ~4500 bytes to the driver,
> > though I don't have any numbers if this is a problem in reality.
>
> I doubt that will be a problem (if it is a problem, you need to shoot
> the piece of hardware generating your bogus long frames anyway).
>
> > Another thing is that eventually some drivers will have to disable HW
> > checksumming to receive tagged frames, and this will have some real
> > potential to hurt performance.
>
> That is definately an issue, and will need to be enabled with a module
> argument or one of the other ideas floated around...
>
> > > I also do NOT want to have driver patches in the
> > > VLAN patch if possible,
> >
> > ACK, my thoughts were to have some sort of "driver patch repository"
> > where you can pick your needed driver patches, close to the current
> > situation where some patches are included in the HOWTO. For example,
> > from spec reading I think my updated 3c59x patch will be a little bit
> > longer than just two changed lines (mainly because the necessary
> > hardware features to receive tagged frames changed quite a bit during
> > the course of the NICs supported by this driver...), so it will
> > probably be unsuitable to cut and paste it from the HOWTO.
>
> I'll be happy to link them to my page and/or store them there, I just
> don't want to add them to vlan_2.4.patch. I'll add them to
> a contrib/ directory in the VLAN distribution though...just email the
> patches to me with instructions to add them (you're name and email
> will be on the patch, not mine :))...
>
> Enjoy,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com>
> President of Candela Technologies Inc http://www.candelatech.com
> ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
>
>
> --__--__--
>
> _______________________________________________
> VLAN mailing list - VLAN@Scry.WANfear.com
> http://www.WANfear.com/mailman/listinfo/vlan
>
>
> End of VLAN Digest
_______________________________________________
VLAN mailing list - VLAN@Scry.WANfear.com
http://www.WANfear.com/mailman/listinfo/vlan
VLAN Page: http://scry.wanfear.com/~greear/vlan.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic