netdev
[Top] [All Lists]

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

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission
From: Matti Aarnio <matti.aarnio@xxxxxxxxxxx>
Date: Sun, 7 Jan 2001 21:24:14 +0200
Cc: linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.GSO.4.30.0101071408140.18916-100000@shell.cyberus.ca>; from hadi@cyberus.ca on Sun, Jan 07, 2001 at 02:10:52PM -0500
References: <20010107210036.G25076@mea-ext.zmailer.org> <Pine.GSO.4.30.0101071408140.18916-100000@shell.cyberus.ca>
Sender: owner-netdev@xxxxxxxxxxx
On Sun, Jan 07, 2001 at 02:10:52PM -0500, jamal wrote:
> On Sun, 7 Jan 2001, Matti Aarnio wrote:
> >     Read what I wrote about the issue to Alan.
> >     Ben's code has no problems with receiving VLANs with network
> >     cards which have "hardware support" for VLANs.
> 
> OK. I suppose an skb->vlan_tag is passed to the driver and it will know
> what to do with it (pass it on a descriptor etc).

        Sure, nice.  WHY SHOULD THERE BE MORE LAYER-2 STUFF ADDED TO
        SKB OBJECTS ?

        One of important abstraction issues is to isolate device specific
        new things (like what VLAN/PVC/SVC is used at your favourtite
        802.1Q/ATM/X.25/FrameRelay connection).

        The less we leak that kind of things to SKB, the better, IMO.
        They are net_device issues, after all.

        Tell me (if you can), why packet sender calls hardware-header
        generation for packet, if the card can insert it for you ?
        Consider the structure of Ethernet MAC header, where is source
        address ?  Where is the destination address ?  If you write the
        destination, why should you not write the source there too ?

        No doubt some cards can fill in the source address while doing
        frame transmit, but is it worth the hazzle ?

> cheers,
> jamal

/Matti Aarnio

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