[Top] [All Lists]

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission

To: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission
From: Matti Aarnio <matti.aarnio@xxxxxxxxxxx>
Date: Sun, 7 Jan 2001 17:33:06 +0200
Cc: Ben Greear <greearb@xxxxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <E14FG60-0002eP-00@xxxxxxxxxxxxxxxxx>; from alan@xxxxxxxxxxxxxxxxxxx on Sun, Jan 07, 2001 at 01:42:50PM +0000
References: <3A57EB5E.966C91DA@xxxxxxxxxxxxxxx> <E14FG60-0002eP-00@xxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On Sun, Jan 07, 2001 at 01:42:50PM +0000, Alan Cox wrote:
> > + *      NOTE:  That is no longer true with the addition of VLAN tags.  Not
> > + *             sure which should go first, but I bet it won't make much
> > + *             difference if we are running VLANs.  The good news is that
> It makes a lot of difference tha the vlan goes 2nd. Most sane people wont
> have vlans active on a high load interface.

        VLAN tag header appears as Layer-3 protocol, which then
        causes loop into VLAN reception code and back to generic
        Layer-3 receiver.

        I just tried to pull data from another machine, which
        is on normal port thru VLAN trunking port to receiving
        machine, and got fast-ether at wire speed. (As near as
        ncftp's 11.11 MB/sec is wirespeed..)

> So fix the algorithm. You want the list sorted at this point, or to generate
> a bitmap of free/used entries and scan the list then scan the map
> Question: How do devices with hardware vlan support fit into your model ?

        Hardware VLAN support at several network cards is just
        to recognize VLAN tags, and then do the right thing
        ( = skip 4 bytes ) when doing TCP/UDP checksum.

> Alan

/Matti Aarnio

<Prev in Thread] Current Thread [Next in Thread>