1. 21 10月, 2010 3 次提交
    • J
      vlan: Centralize handling of hardware acceleration. · 3701e513
      Jesse Gross 提交于
      Currently each driver that is capable of vlan hardware acceleration
      must be aware of the vlan groups that are configured and then pass
      the stripped tag to a specialized receive function.  This is
      
      different from other types of hardware offload in that it places a
      significant amount of knowledge in the driver itself rather keeping
      it in the networking core.
      
      This makes vlan offloading function more similarly to other forms
      of offloading (such as checksum offloading or TSO) by doing the
      following:
      * On receive, stripped vlans are passed directly to the network
      core, without attempting to check for vlan groups or reconstructing
      the header if no group
      * vlans are made less special by folding the logic into the main
      receive routines
      * On transmit, the device layer will add the vlan header in software
      if the hardware doesn't support it, instead of spreading that logic
      out in upper layers, such as bonding.
      
      There are a number of advantages to this:
      * Fixes all bugs with drivers incorrectly dropping vlan headers at once.
      * Avoids having to disable VLAN acceleration when in promiscuous mode
      (good for bridging since it always puts devices in promiscuous mode).
      * Keeps VLAN tag separate until given to ultimate consumer, which
      avoids needing to do header reconstruction as in tg3 unless absolutely
      necessary.
      * Consolidates common code in core networking.
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3701e513
    • J
      vlan: Avoid hash table lookup to find group. · 65ac6a5f
      Jesse Gross 提交于
      A struct net_device always maps to zero or one vlan groups and we
      always know the device when we are looking up a group.  We currently
      do a hash table lookup on the device to find the group but it is
      much simpler to just store a pointer.
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      65ac6a5f
    • J
      vlan: Rename VLAN_GROUP_ARRAY_LEN to VLAN_N_VID. · b738127d
      Jesse Gross 提交于
      VLAN_GROUP_ARRAY_LEN is simply the number of possible vlan VIDs.
      Since vlan groups will soon be more of an implementation detail
      for vlan devices, rename the constant to be descriptive of its
      actual purpose.
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b738127d
  2. 23 8月, 2010 1 次提交
  3. 27 11月, 2009 1 次提交
  4. 30 10月, 2009 1 次提交
  5. 28 10月, 2009 1 次提交
  6. 27 10月, 2009 1 次提交
    • E
      vlan: allow null VLAN ID to be used · 05423b24
      Eric Dumazet 提交于
      We currently use a 16 bit field (vlan_tci) to store VLAN ID/PRIO on a skb.
      
      Null value is used as a special value, meaning vlan tagging not enabled.
      This forbids use of null vlan ID.
      
      As pointed by David, some drivers use the 3 high order bits (PRIO)
      
      As VLAN ID is 12 bits, we can use the remaining bit (CFI) as a flag, and
      allow null VLAN ID.
      
      In case future code really wants to use VLAN_CFI_MASK, we'll have to use
      a bit outside of vlan_tci.
      
      #define VLAN_PRIO_MASK         0xe000 /* Priority Code Point */
      #define VLAN_PRIO_SHIFT        13
      #define VLAN_CFI_MASK          0x1000 /* Canonical Format Indicator */
      #define VLAN_TAG_PRESENT       VLAN_CFI_MASK
      #define VLAN_VID_MASK          0x0fff /* VLAN Identifier */
      Reported-by: NGertjan Hofman <gertjan_hofman@yahoo.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05423b24
  7. 16 4月, 2009 1 次提交
  8. 19 2月, 2009 1 次提交
  9. 07 1月, 2009 1 次提交
    • H
      vlan: Add GRO interfaces · e1c096e2
      Herbert Xu 提交于
      This patch adds GRO interfaces for hardware-assisted VLAN reception.
      With this in place we're now at parity with LRO as far as the
      interface is concerned.  That is, you can now take any LRO driver
      and convert it over to GRO.
      
      As the CB memory clashes with GRO's use of CB, I've removed it
      entirely by storing dev in skb->dev.  This is OK because VLAN
      gets called first thing in netif_receive_skb and skb->dev is
      not used in between us calling netif_rx and netif_receive_skb
      getting called.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1c096e2
  10. 05 11月, 2008 1 次提交
    • P
      net: fix packet socket delivery in rx irq handler · 9b22ea56
      Patrick McHardy 提交于
      The changes to deliver hardware accelerated VLAN packets to packet
      sockets (commit bc1d0411) caused a warning for non-NAPI drivers.
      The __vlan_hwaccel_rx() function is called directly from the drivers
      RX function, for non-NAPI drivers that means its still in RX IRQ
      context:
      
      [   27.779463] ------------[ cut here ]------------
      [   27.779509] WARNING: at kernel/softirq.c:136 local_bh_enable+0x37/0x81()
      ...
      [   27.782520]  [<c0264755>] netif_nit_deliver+0x5b/0x75
      [   27.782590]  [<c02bba83>] __vlan_hwaccel_rx+0x79/0x162
      [   27.782664]  [<f8851c1d>] atl1_intr+0x9a9/0xa7c [atl1]
      [   27.782738]  [<c0155b17>] handle_IRQ_event+0x23/0x51
      [   27.782808]  [<c015692e>] handle_edge_irq+0xc2/0x102
      [   27.782878]  [<c0105fd5>] do_IRQ+0x4d/0x64
      
      Split hardware accelerated VLAN reception into two parts to fix this:
      
      - __vlan_hwaccel_rx just stores the VLAN TCI and performs the VLAN
        device lookup, then calls netif_receive_skb()/netif_rx()
      
      - vlan_hwaccel_do_receive(), which is invoked by netif_receive_skb()
        in softirq context, performs the real reception and delivery to
        packet sockets.
      Reported-and-tested-by: NRamon Casellas <ramon.casellas@cttc.es>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b22ea56
  11. 15 7月, 2008 1 次提交
    • P
      vlan: Don't store VLAN tag in cb · 6aa895b0
      Patrick McHardy 提交于
      Use a real skb member to store the skb to avoid clashes with qdiscs,
      which are allowed to use the cb area themselves. As currently only real
      devices that consume the skb set the NETIF_F_HW_VLAN_TX flag, no explicit
      invalidation is neccessary.
      
      The new member fills a hole on 64 bit, the skb layout changes from:
      
              __u32                      mark;                 /*   172     4 */
              sk_buff_data_t             transport_header;     /*   176     4 */
              sk_buff_data_t             network_header;       /*   180     4 */
              sk_buff_data_t             mac_header;           /*   184     4 */
              sk_buff_data_t             tail;                 /*   188     4 */
              /* --- cacheline 3 boundary (192 bytes) --- */
              sk_buff_data_t             end;                  /*   192     4 */
      
              /* XXX 4 bytes hole, try to pack */
      
      to
      
              __u32                      mark;                 /*   172     4 */
              __u16                      vlan_tci;             /*   176     2 */
      
              /* XXX 2 bytes hole, try to pack */
      
              sk_buff_data_t             transport_header;     /*   180     4 */
              sk_buff_data_t             network_header;       /*   184     4 */
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6aa895b0
  12. 09 7月, 2008 1 次提交
    • P
      vlan: avoid header copying and linearisation where possible · 11a100f8
      Patrick McHardy 提交于
      - vlan_dev_reorder_header() is only called on the receive path after
        calling skb_share_check(). This means we can use skb_cow() since
        all we need is a writable header.
      
      - vlan_dev_hard_header() includes a work-around for some apparently
        broken out of tree MPLS code. The hard_header functions can expect
        to always have a headroom of at least there own hard_header_len
        available, so the reallocation check is unnecessary.
      
      - __vlan_put_tag() can use skb_cow_head() to avoid the skb_unshare()
        copy when the header is writable.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11a100f8
  13. 08 7月, 2008 5 次提交
  14. 06 7月, 2008 1 次提交
    • P
      vlan: Add GVRP support · 70c03b49
      Patrick McHardy 提交于
      Add GVRP support for dynamically registering VLANs with switches.
      
      By default GVRP is disabled because we only support the applicant-only
      participant model, which means it should not be enabled on vlans that
      are members of a bridge. Since there is currently no way to cleanly
      determine that, the user is responsible for enabling it.
      
      The code is pretty small and low impact, its wrapped in a config
      option though because it depends on the GARP implementation and
      the STP core.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      70c03b49
  15. 16 4月, 2008 1 次提交
  16. 27 3月, 2008 1 次提交
    • P
      [VLAN]: Reduce memory consumed by vlan_groups · 67727184
      Pavel Emelyanov 提交于
      Currently each vlan_groupd contains 8 pointers on arrays with 512
      pointers on struct net_device each  :)  Such a construction "in many
      cases ... wastes memory".
      
      My proposal is to allow for some of these arrays pointers be NULL,
      meaning that there are no devices in it. When a new device is added
      to the vlan_group, the appropriate array is allocated.
      
      The check in vlan_group_get_device's is safe, since the pointer
      vg->vlan_devices_arrays[x] can only switch from NULL to not-NULL.
      The vlan_group_prealloc_vid() is guarded with rtnl lock and is
      also safe.
      
      I've checked (I hope that) all the places, that use these arrays
      and found, that the register_vlan_dev is the only place, that can
      put a vlan device on an empty vlan_group.
      
      Rough calculations shows, that after the patch a setup with a
      single vlan dev (or up to 512 vlans with sequential vids) will
      occupy approximately 8 times less memory.
      
      The question I have is - does this patch makes sense, or a totally
      new structures are required to store the vlan_devs?
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      67727184
  17. 06 2月, 2008 1 次提交
  18. 29 1月, 2008 8 次提交
  19. 11 10月, 2007 1 次提交
    • E
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      Eric W. Biederman 提交于
      This patch makes most of the generic device layer network
      namespace safe.  This patch makes dev_base_head a
      network namespace variable, and then it picks up
      a few associated variables.  The functions:
      dev_getbyhwaddr
      dev_getfirsthwbytype
      dev_get_by_flags
      dev_get_by_name
      __dev_get_by_name
      dev_get_by_index
      __dev_get_by_index
      dev_ioctl
      dev_ethtool
      dev_load
      wireless_process_ioctl
      
      were modified to take a network namespace argument, and
      deal with it.
      
      vlan_ioctl_set and brioctl_set were modified so their
      hooks will receive a network namespace argument.
      
      So basically anthing in the core of the network stack that was
      affected to by the change of dev_base was modified to handle
      multiple network namespaces.  The rest of the network stack was
      simply modified to explicitly use &init_net the initial network
      namespace.  This can be fixed when those components of the network
      stack are modified to handle multiple network namespaces.
      
      For now the ifindex generator is left global.
      
      Fundametally ifindex numbers are per namespace, or else
      we will have corner case problems with migration when
      we get that far.
      
      At the same time there are assumptions in the network stack
      that the ifindex of a network device won't change.  Making
      the ifindex number global seems a good compromise until
      the network stack can cope with ifindex changes when
      you change namespaces, and the like.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      881d966b
  20. 15 7月, 2007 2 次提交
  21. 12 7月, 2007 1 次提交
    • P
      [VLAN]: Fix MAC address handling · 8c979c26
      Patrick McHardy 提交于
      The VLAN MAC address handling is broken in multiple ways. When the address
      differs when setting it, the real device is put in promiscous mode twice,
      but never taken out again. Additionally it doesn't resync when the real
      device's address is changed and needlessly puts it in promiscous mode when
      the vlan device is still down.
      
      Fix by moving address handling to vlan_dev_open/vlan_dev_stop and properly
      deal with address changes in the device notifier. Also switch to
      dev_unicast_add (which needs the exact same handling).
      
      Since the set_mac_address handler is identical to the generic ethernet one
      with these changes, kill it and use ether_setup().
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c979c26
  22. 11 7月, 2007 3 次提交
  23. 26 4月, 2007 2 次提交