1. 15 Dec, 2015 1 commit
  2. 05 Dec, 2015 1 commit
  3. 01 Jun, 2015 1 commit
    • Toshiaki Makita's avatar
      vlan: Add GRO support for non hardware accelerated vlan · 66e5133f
      Toshiaki Makita authored
      Currently packets with non-hardware-accelerated vlan cannot be handled
      by GRO. This causes low performance for 802.1ad and stacked vlan, as their
      vlan tags are currently not stripped by hardware.
      This patch adds GRO support for non-hardware-accelerated vlan and
      improves receive performance of them.
      Test Environment:
       vlan device (.1Q) on vlan device (.1ad) on ixgbe (82599)
      - Before
      $ netperf -t TCP_STREAM -H -l 60
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
       87380  16384  16384    60.00    5233.17
      Rx side CPU usage:
        %usr      %sys      %irq     %soft     %idle
        0.27     58.03      0.00     41.70      0.00
      - After
      $ netperf -t TCP_STREAM -H -l 60
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
       87380  16384  16384    60.00    7586.85
      Rx side CPU usage:
        %usr      %sys      %irq     %soft     %idle
        0.50     25.83      0.00     59.53     14.14
      [ Register VLAN offloads with priority 10 -DaveM ]
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 30 May, 2015 1 commit
  5. 05 May, 2015 1 commit
  6. 29 Mar, 2015 2 commits
  7. 30 Jan, 2015 1 commit
  8. 13 Jan, 2015 1 commit
  9. 21 Nov, 2014 5 commits
  10. 11 Aug, 2014 1 commit
    • Vlad Yasevich's avatar
      net: Always untag vlan-tagged traffic on input. · 0d5501c1
      Vlad Yasevich authored
      Currently the functionality to untag traffic on input resides
      as part of the vlan module and is build only when VLAN support
      is enabled in the kernel.  When VLAN is disabled, the function
      vlan_untag() turns into a stub and doesn't really untag the
      packets.  This seems to create an interesting interaction
      between VMs supporting checksum offloading and some network drivers.
      There are some drivers that do not allow the user to change
      tx-vlan-offload feature of the driver.  These drivers also seem
      to assume that any VLAN-tagged traffic they transmit will
      have the vlan information in the vlan_tci and not in the vlan
      header already in the skb.  When transmitting skbs that already
      have tagged data with partial checksum set, the checksum doesn't
      appear to be updated correctly by the card thus resulting in a
      failure to establish TCP connections.
      The following is a packet trace taken on the receiver where a
      sender is a VM with a VLAN configued.  The host VM is running on
      doest not have VLAN support and the outging interface on the
      host is tg3:
      10:12:43.503055 52:54:00:ae:42:3f > 28:d2:44:7d:c2:de, ethertype 802.1Q
      (0x8100), length 78: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 27243,
      offset 0, flags [DF], proto TCP (6), length 60)
 > Flags [S], cksum 0xdc39 (incorrect
      -> 0x48d9), seq 1069378582, win 29200, options [mss 1460,sackOK,TS val
      4294837885 ecr 0,nop,wscale 7], length 0
      10:12:44.505556 52:54:00:ae:42:3f > 28:d2:44:7d:c2:de, ethertype 802.1Q
      (0x8100), length 78: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 27244,
      offset 0, flags [DF], proto TCP (6), length 60)
 > Flags [S], cksum 0xdc39 (incorrect
      -> 0x44ee), seq 1069378582, win 29200, options [mss 1460,sackOK,TS val
      4294838888 ecr 0,nop,wscale 7], length 0
      This connection finally times out.
      I've only access to the TG3 hardware in this configuration thus have
      only tested this with TG3 driver.  There are a lot of other drivers
      that do not permit user changes to vlan acceleration features, and
      I don't know if they all suffere from a similar issue.
      The patch attempt to fix this another way.  It moves the vlan header
      stipping code out of the vlan module and always builds it into the
      kernel network core.  This way, even if vlan is not supported on
      a virtualizatoin host, the virtual machines running on top of such
      host will still work with VLANs enabled.
      CC: Patrick McHardy <kaber@trash.net>
      CC: Nithin Nayak Sujir <nsujir@broadcom.com>
      CC: Michael Chan <mchan@broadcom.com>
      CC: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  11. 20 May, 2014 1 commit
  12. 16 May, 2014 2 commits
    • Vlad Yasevich's avatar
      bonding: Fix stacked device detection in arp monitoring · 44a40855
      Vlad Yasevich authored
      Prior to commit fbd929f2
      	bonding: support QinQ for bond arp interval
      the arp monitoring code allowed for proper detection of devices
      stacked on top of vlans.  Since the above commit, the
      code can still detect a device stacked on top of single
      vlan, but not a device stacked on top of Q-in-Q configuration.
      The search will only set the inner vlan tag if the route
      device is the vlan device.  However, this is not always the
      case, as it is possible to extend the stacked configuration.
      With this patch it is possible to provision devices on
      top Q-in-Q vlan configuration that should be used as
      a source of ARP monitoring information.
      For example:
      ip link add link bond0 vlan10 type vlan proto 802.1q id 10
      ip link add link vlan10 vlan100 type vlan proto 802.1q id 100
      ip link add link vlan100 type macvlan
      Note:  This patch limites the number of stacked VLANs to 2,
      just like before.  The original, however had another issue
      in that if we had more then 2 levels of VLANs, we would end
      up generating incorrectly tagged traffic.  This is no longer
      Fixes: fbd929f2 (bonding: support QinQ for bond arp interval)
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@redhat.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Ding Tianhong <dingtianhong@huawei.com>
      CC: Patric McHardy <kaber@trash.net>
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Vlad Yasevich's avatar
      vlan: Fix lockdep warning with stacked vlan devices. · d38569ab
      Vlad Yasevich authored
      This reverts commit dc8eaaa0.
      	vlan: Fix lockdep warning when vlan dev handle notification
      Instead we use the new new API to find the lock subclass of
      our vlan device.  This way we can support configurations where
      vlans are interspersed with other devices:
        bond -> vlan -> macvlan -> vlan
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  13. 12 May, 2014 1 commit
  14. 26 Mar, 2014 1 commit
  15. 24 Mar, 2014 1 commit
  16. 05 Jan, 2014 1 commit
  17. 10 Nov, 2013 1 commit
  18. 07 Nov, 2013 1 commit
  19. 18 Jul, 2013 1 commit
    • Eric Dumazet's avatar
      vlan: mask vlan prio bits · d4b812de
      Eric Dumazet authored
      In commit 48cc32d3
      ("vlan: don't deliver frames for unknown vlans to protocols")
      Florian made sure we set pkt_type to PACKET_OTHERHOST
      if the vlan id is set and we could find a vlan device for this
      particular id.
      But we also have a problem if prio bits are set.
      Steinar reported an issue on a router receiving IPv6 frames with a
      vlan tag of 4000 (id 0, prio 2), and tunneled into a sit device,
      because skb->vlan_tci is set.
      Forwarded frame is completely corrupted : We can see (8100:4000)
      being inserted in the middle of IPv6 source address :
      16:48:00.780413 IP6 2001:16d8:8100:4000:ee1c:0:9d9:bc87 >
      9f94:4d95:2001:67c:29f4::: ICMP6, unknown icmp6 type (0), length 64
             0x0000:  0000 0029 8000 c7c3 7103 0001 a0ae e651
             0x0010:  0000 0000 ccce 0b00 0000 0000 1011 1213
             0x0020:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
             0x0030:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
      It seems we are not really ready to properly cope with this right now.
      We can probably do better in future kernels :
      vlan_get_ingress_priority() should be a netdev property instead of
      a per vlan_dev one.
      For stable kernels, lets clear vlan_tci to fix the bugs.
      Reported-by: default avatarSteinar H. Gunderson <sesse@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  20. 20 Jun, 2013 1 commit
  21. 07 Jun, 2013 1 commit
  22. 21 Apr, 2013 1 commit
  23. 19 Apr, 2013 5 commits
  24. 27 Mar, 2013 1 commit
    • Simon Horman's avatar
      net: add ETH_P_802_3_MIN · e5c5d22e
      Simon Horman authored
      Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
      an 802.3 frame. Frames with a lower value in the ethernet type field
      are Ethernet II.
      Also update all the users of this value that David Miller and
      I could find to use the new constant.
      Also correct a bug in util.c. The comparison with ETH_P_802_3_MIN
      should be >= not >.
      As suggested by Jesse Gross.
      Compile tested only.
      Cc: David Miller <davem@davemloft.net>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Bart De Schuymer <bart.de.schuymer@pandora.be>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: linux-bluetooth@vger.kernel.org
      Cc: netfilter-devel@vger.kernel.org
      Cc: bridge@lists.linux-foundation.org
      Cc: linux-wireless@vger.kernel.org
      Cc: linux1394-devel@lists.sourceforge.net
      Cc: linux-media@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: dev@openvswitch.org
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Acked-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  25. 23 Feb, 2013 1 commit
    • Cong Wang's avatar
      vlan: adjust vlan_set_encap_proto() for its callers · da8c8724
      Cong Wang authored
      There are two places to call vlan_set_encap_proto():
      vlan_untag() and __pop_vlan_tci().
      vlan_untag() assumes skb->data points after mac addr, otherwise
      the following code
              vhdr = (struct vlan_hdr *) skb->data;
              vlan_tci = ntohs(vhdr->h_vlan_TCI);
              __vlan_hwaccel_put_tag(skb, vlan_tci);
              skb_pull_rcsum(skb, VLAN_HLEN);
      won't be correct. But __pop_vlan_tci() assumes points _before_
      mac addr.
      In vlan_set_encap_proto(), it looks for some magic L2 value
      after mac addr:
              rawp = skb->data;
              if (*(unsigned short *) rawp == 0xFFFF)
      Therefore __pop_vlan_tci() is obviously wrong.
      A quick fix is avoiding using skb->data in vlan_set_encap_proto(),
      use 'vhdr+1' is always correct in both cases.
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jesse Gross <jesse@nicira.com>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Acked-by: default avatarJesse Gross <jesse@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  26. 13 Oct, 2012 1 commit
  27. 08 Oct, 2012 1 commit
    • Florian Zumbiehl's avatar
      vlan: don't deliver frames for unknown vlans to protocols · 48cc32d3
      Florian Zumbiehl authored
      6a32e4f9 made the vlan code skip marking
      vlan-tagged frames for not locally configured vlans as PACKET_OTHERHOST if
      there was an rx_handler, as the rx_handler could cause the frame to be received
      on a different (virtual) vlan-capable interface where that vlan might be
      As rx_handlers do not necessarily return RX_HANDLER_ANOTHER, this could cause
      frames for unknown vlans to be delivered to the protocol stack as if they had
      been received untagged.
      For example, if an ipv6 router advertisement that's tagged for a locally not
      configured vlan is received on an interface with macvlan interfaces attached,
      macvlan's rx_handler returns RX_HANDLER_PASS after delivering the frame to the
      macvlan interfaces, which caused it to be passed to the protocol stack, leading
      to ipv6 addresses for the announced prefix being configured even though those
      are completely unusable on the underlying interface.
      The fix moves marking as PACKET_OTHERHOST after the rx_handler so the
      rx_handler, if there is one, sees the frame unchanged, but afterwards,
      before the frame is delivered to the protocol stack, it gets marked whether
      there is an rx_handler or not.
      Signed-off-by: default avatarFlorian Zumbiehl <florz@florz.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  28. 24 Aug, 2012 1 commit
  29. 19 Mar, 2012 1 commit
  30. 04 Mar, 2012 1 commit
    • Paul Gortmaker's avatar
      BUG: headers with BUG/BUG_ON etc. need linux/bug.h · 187f1882
      Paul Gortmaker authored
      If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
      other BUG variant in a static inline (i.e. not in a #define) then
      that header really should be including <linux/bug.h> and not just
      expecting it to be implicitly present.
      We can make this change risk-free, since if the files using these
      headers didn't have exposure to linux/bug.h already, they would have
      been causing compile failures/warnings.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>