lkml.org 
[lkml]   [2007]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?
    Ben Greear wrote:
    > Stephen Hemminger wrote:
    >> On Wed, 31 Oct 2007 14:43:51 -0400
    >> Dave Johnson <djohnson+linux-kernel@sw.starentnetworks.com> wrote:
    >>
    >>
    >>> Depending on the network driver, I'm seeing different behavior if
    >>> a .1q packet is received to an PF_PACKET, SOCK_RAW, ETH_P_ALL socket.
    >>>
    >>>
    >>> On devices what do not use NETIF_F_HW_VLAN_RX, the packet socket gets
    >>> the complete packet with vlan tag included as the driver simply calls
    >>> netif_receive_skb() or equivilant. packet_rcv() then gets the whole
    >>> thing vlan tag included and sends this through the socket.
    >>>
    >>> vlan_skb_recv() also gets these all and will drop them because there
    >>> are no vlans configured.
    >>>
    >>>
    >>
    >> The VLAN acceleration grabs and hides the tag. It is a design flaw
    >> that should be fixed, feel free to post a patch.
    >>
    > There may be several ways to 'fix' this. Perhaps it would be worth
    > discussing what
    > we want the end result to be at least?
    >
    > Should we always pass the vlan header up to raw sockets as part of the
    > data payload?
    >
    > Or, maybe pass it in an auxiliary message such as how timestamps may
    > be passed?
    >
    > The first option seems cleaner, but maybe there are performance
    > problems with this
    > approach?
    >
    > We should also define what a NIC should do with VLANs it doesn't
    > explicitly know
    > about. I think it should pass them up the stack with VLAN tag
    > intact, but again, perhaps
    > there are reasons not to do that?
    >
    > DaveM did the HW Accel for VLANs if I remember correctly...perhaps he
    > has some input?

    The code in AF_PACKET should fix the skb before passing to user space so
    that there is
    no difference between accel and non-accel hardware. Internal choices
    shouldn't
    leak to user space. Ditto, the receive checksum offload should be fixed
    up as well.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-01 02:27    [W:0.026 / U:30.720 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site