1. 23 5月, 2014 1 次提交
    • M
      vlan: more careful checksum features handling · da08143b
      Michal Kubeček 提交于
      When combining real_dev's features and vlan_features, simple
      bitwise AND is used. This doesn't work well for checksum
      offloading features as if one set has NETIF_F_HW_CSUM and the
      other NETIF_F_IP_CSUM and/or NETIF_F_IPV6_CSUM, we end up with
      no checksum offloading. However, from the logical point of view
      (how can_checksum_protocol() works), NETIF_F_HW_CSUM contains
      the functionality of NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM so
      that the result should be IP/IPV6.
      
      Add helper function netdev_intersect_features() implementing
      this logic and use it in vlan_dev_fix_features().
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da08143b
  2. 14 5月, 2014 1 次提交
  3. 08 5月, 2014 1 次提交
  4. 21 4月, 2014 1 次提交
  5. 04 4月, 2014 1 次提交
  6. 01 4月, 2014 4 次提交
  7. 30 3月, 2014 2 次提交
  8. 29 3月, 2014 2 次提交
  9. 18 3月, 2014 1 次提交
    • E
      netpoll: Remove dead packet receive code (CONFIG_NETPOLL_TRAP) · 9c62a68d
      Eric W. Biederman 提交于
      The netpoll packet receive code only becomes active if the netpoll
      rx_skb_hook is implemented, and there is not a single implementation
      of the netpoll rx_skb_hook in the kernel.
      
      All of the out of tree implementations I have found all call
      netpoll_poll which was removed from the kernel in 2011, so this
      change should not add any additional breakage.
      
      There are problems with the netpoll packet receive code.  __netpoll_rx
      does not call dev_kfree_skb_irq or dev_kfree_skb_any in hard irq
      context.  netpoll_neigh_reply leaks every skb it receives.  Reception
      of packets does not work successfully on stacked devices (aka bonding,
      team, bridge, and vlans).
      
      Given that the netpoll packet receive code is buggy, there are no
      out of tree users that will be merged soon, and the code has
      not been used for in tree for a decade let's just remove it.
      
      Reverting this commit can server as a starting point for anyone
      who wants to resurrect netpoll packet reception support.
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c62a68d
  10. 12 3月, 2014 1 次提交
  11. 28 2月, 2014 1 次提交
    • L
      net: move net_device priv_flags out from UAPI · 7aa98047
      Luis R. Rodriguez 提交于
      These are private to userspace, and they're unstable
      anyway and can be shuffled at will (see 080e4130)
      so any userspace application relying on them is on crack.
      
      Test compiled with allyesconfig.
      
      mcgrof@drvbp1 /pub/mem/mcgrof/net-next (git::master)$ make allyesconfig
      mcgrof@drvbp1 /pub/mem/mcgrof/net-next (git::master)$ time make -j 20
      ...
        BUILD   arch/x86/boot/bzImage
      Setup is 16992 bytes (padded to 17408 bytes).
      System is 56153 kB
      CRC 721d2751
      Kernel: arch/x86/boot/bzImage is ready  (#1)
      real    19m35.744s
      user    280m37.984s
      sys     27m54.104s
      
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7aa98047
  12. 27 2月, 2014 1 次提交
  13. 19 2月, 2014 1 次提交
  14. 17 2月, 2014 2 次提交
  15. 15 2月, 2014 1 次提交
  16. 14 2月, 2014 1 次提交
  17. 23 1月, 2014 1 次提交
  18. 22 1月, 2014 1 次提交
    • O
      net: Add GRO support for UDP encapsulating protocols · b582ef09
      Or Gerlitz 提交于
      Add GRO handlers for protocols that do UDP encapsulation, with the intent of
      being able to coalesce packets which encapsulate packets belonging to
      the same TCP session.
      
      For GRO purposes, the destination UDP port takes the role of the ether type
      field in the ethernet header or the next protocol in the IP header.
      
      The UDP GRO handler will only attempt to coalesce packets whose destination
      port is registered to have gro handler.
      
      Use a mark on the skb GRO CB data to disallow (flush) running the udp gro receive
      code twice on a packet. This solves the problem of udp encapsulated packets whose
      inner VM packet is udp and happen to carry a port which has registered offloads.
      Signed-off-by: NShlomo Pongratz <shlomop@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b582ef09
  19. 18 1月, 2014 1 次提交
  20. 17 1月, 2014 2 次提交
  21. 16 1月, 2014 1 次提交
    • V
      net: rename sysfs symlinks on device name change · 5bb025fa
      Veaceslav Falico 提交于
      Currently, we don't rename the upper/lower_ifc symlinks in
      /sys/class/net/*/ , which might result stale/duplicate links/names.
      
      Fix this by adding netdev_adjacent_rename_links(dev, oldname) which renames
      all the upper/lower interface's links to dev from the upper/lower_oldname
      to the new name.
      
      We don't need a rollback because only we control these symlinks and if we
      fail to rename them - sysfs will anyway complain.
      Reported-by: NDing Tianhong <dingtianhong@huawei.com>
      CC: Ding Tianhong <dingtianhong@huawei.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Eric Dumazet <edumazet@google.com>
      CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      CC: Cong Wang <amwang@redhat.com>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5bb025fa
  22. 11 1月, 2014 1 次提交
    • J
      net: core: explicitly select a txq before doing l2 forwarding · f663dd9a
      Jason Wang 提交于
      Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
      will cause several issues:
      
      - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
        instead of lower device which misses the necessary txq synchronization for
        lower device such as txq stopping or frozen required by dev watchdog or
        control path.
      - dev_hard_start_xmit() was called with NULL txq which bypasses the net device
        watchdog.
      - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
        when tso is disabled for lower device.
      
      Fix this by explicitly introducing a new param for .ndo_select_queue() for just
      selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
      extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
      forwarding transmission.
      
      With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
      to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
      a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
      dev_queue_xmit() to do the transmission.
      
      In the future, it was also required for macvtap l2 forwarding support since it
      provides a necessary synchronization method.
      
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f663dd9a
  23. 08 1月, 2014 1 次提交
    • J
      net-gre-gro: Add GRE support to the GRO stack · bf5a755f
      Jerry Chu 提交于
      This patch built on top of Commit 299603e8
      ("net-gro: Prepare GRO stack for the upcoming tunneling support") to add
      the support of the standard GRE (RFC1701/RFC2784/RFC2890) to the GRO
      stack. It also serves as an example for supporting other encapsulation
      protocols in the GRO stack in the future.
      
      The patch supports version 0 and all the flags (key, csum, seq#) but
      will flush any pkt with the S (seq#) flag. This is because the S flag
      is not support by GSO, and a GRO pkt may end up in the forwarding path,
      thus requiring GSO support to break it up correctly.
      
      Currently the "packet_offload" structure only contains L3 (ETH_P_IP/
      ETH_P_IPV6) GRO offload support so the encapped pkts are limited to
      IP pkts (i.e., w/o L2 hdr). But support for other protocol type can
      be easily added, so is the support for GRE variations like NVGRE.
      
      The patch also support csum offload. Specifically if the csum flag is on
      and the h/w is capable of checksumming the payload (CHECKSUM_COMPLETE),
      the code will take advantage of the csum computed by the h/w when
      validating the GRE csum.
      
      Note that commit 60769a5d "ipv4: gre:
      add GRO capability" already introduces GRO capability to IPv4 GRE
      tunnels, using the gro_cells infrastructure. But GRO is done after
      GRE hdr has been removed (i.e., decapped). The following patch applies
      GRO when pkts first come in (before hitting the GRE tunnel code). There
      is some performance advantage for applying GRO as early as possible.
      Also this approach is transparent to other subsystem like Open vSwitch
      where GRE decap is handled outside of the IP stack hence making it
      harder for the gro_cells stuff to apply. On the other hand, some NICs
      are still not capable of hashing on the inner hdr of a GRE pkt (RSS).
      In that case the GRO processing of pkts from the same remote host will
      all happen on the same CPU and the performance may be suboptimal.
      
      I'm including some rough preliminary performance numbers below. Note
      that the performance will be highly dependent on traffic load, mix as
      usual. Moreover it also depends on NIC offload features hence the
      following is by no means a comprehesive study. Local testing and tuning
      will be needed to decide the best setting.
      
      All tests spawned 50 copies of netperf TCP_STREAM and ran for 30 secs.
      (super_netperf 50 -H 192.168.1.18 -l 30)
      
      An IP GRE tunnel with only the key flag on (e.g., ip tunnel add gre1
      mode gre local 10.246.17.18 remote 10.246.17.17 ttl 255 key 123)
      is configured.
      
      The GRO support for pkts AFTER decap are controlled through the device
      feature of the GRE device (e.g., ethtool -K gre1 gro on/off).
      
      1.1 ethtool -K gre1 gro off; ethtool -K eth0 gro off
      thruput: 9.16Gbps
      CPU utilization: 19%
      
      1.2 ethtool -K gre1 gro on; ethtool -K eth0 gro off
      thruput: 5.9Gbps
      CPU utilization: 15%
      
      1.3 ethtool -K gre1 gro off; ethtool -K eth0 gro on
      thruput: 9.26Gbps
      CPU utilization: 12-13%
      
      1.4 ethtool -K gre1 gro on; ethtool -K eth0 gro on
      thruput: 9.26Gbps
      CPU utilization: 10%
      
      The following tests were performed on a different NIC that is capable of
      csum offload. I.e., the h/w is capable of computing IP payload csum
      (CHECKSUM_COMPLETE).
      
      2.1 ethtool -K gre1 gro on (hence will use gro_cells)
      
      2.1.1 ethtool -K eth0 gro off; csum offload disabled
      thruput: 8.53Gbps
      CPU utilization: 9%
      
      2.1.2 ethtool -K eth0 gro off; csum offload enabled
      thruput: 8.97Gbps
      CPU utilization: 7-8%
      
      2.1.3 ethtool -K eth0 gro on; csum offload disabled
      thruput: 8.83Gbps
      CPU utilization: 5-6%
      
      2.1.4 ethtool -K eth0 gro on; csum offload enabled
      thruput: 8.98Gbps
      CPU utilization: 5%
      
      2.2 ethtool -K gre1 gro off
      
      2.2.1 ethtool -K eth0 gro off; csum offload disabled
      thruput: 5.93Gbps
      CPU utilization: 9%
      
      2.2.2 ethtool -K eth0 gro off; csum offload enabled
      thruput: 5.62Gbps
      CPU utilization: 8%
      
      2.2.3 ethtool -K eth0 gro on; csum offload disabled
      thruput: 7.69Gbps
      CPU utilization: 8%
      
      2.2.4 ethtool -K eth0 gro on; csum offload enabled
      thruput: 8.96Gbps
      CPU utilization: 5-6%
      Signed-off-by: NH.K. Jerry Chu <hkchu@google.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf5a755f
  24. 05 1月, 2014 1 次提交
  25. 04 1月, 2014 1 次提交
  26. 03 1月, 2014 1 次提交
    • W
      ipv4: fix tunneled VM traffic over hw VXLAN/GRE GSO NIC · 7a7ffbab
      Wei-Chun Chao 提交于
      VM to VM GSO traffic is broken if it goes through VXLAN or GRE
      tunnel and the physical NIC on the host supports hardware VXLAN/GRE
      GSO offload (e.g. bnx2x and next-gen mlx4).
      
      Two issues -
      (VXLAN) VM traffic has SKB_GSO_DODGY and SKB_GSO_UDP_TUNNEL with
      SKB_GSO_TCP/UDP set depending on the inner protocol. GSO header
      integrity check fails in udp4_ufo_fragment if inner protocol is
      TCP. Also gso_segs is calculated incorrectly using skb->len that
      includes tunnel header. Fix: robust check should only be applied
      to the inner packet.
      
      (VXLAN & GRE) Once GSO header integrity check passes, NULL segs
      is returned and the original skb is sent to hardware. However the
      tunnel header is already pulled. Fix: tunnel header needs to be
      restored so that hardware can perform GSO properly on the original
      packet.
      Signed-off-by: NWei-Chun Chao <weichunc@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a7ffbab
  27. 02 1月, 2014 1 次提交
    • S
      net: core functions cleanup · 1d143d9f
      stephen hemminger 提交于
      The following functions are not used outside of net/core/dev.c
      and should be declared static.
      
        call_netdevice_notifiers_info
        __dev_remove_offload
        netdev_has_any_upper_dev
        __netdev_adjacent_dev_remove
        __netdev_adjacent_dev_link_lists
        __netdev_adjacent_dev_unlink_lists
        __netdev_adjacent_dev_unlink
        __netdev_adjacent_dev_link_neighbour
        __netdev_adjacent_dev_unlink_neighbour
      
      And the following are never used and should be deleted
        netdev_lower_dev_get_private_rcu
        __netdev_find_adj_rcu
      Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d143d9f
  28. 01 1月, 2014 1 次提交
    • D
      vlan: Fix header ops passthru when doing TX VLAN offload. · 2205369a
      David S. Miller 提交于
      When the vlan code detects that the real device can do TX VLAN offloads
      in hardware, it tries to arrange for the real device's header_ops to
      be invoked directly.
      
      But it does so illegally, by simply hooking the real device's
      header_ops up to the VLAN device.
      
      This doesn't work because we will end up invoking a set of header_ops
      routines which expect a device type which matches the real device, but
      will see a VLAN device instead.
      
      Fix this by providing a pass-thru set of header_ops which will arrange
      to pass the proper real device instead.
      
      To facilitate this add a dev_rebuild_header().  There are
      implementations which provide a ->cache and ->create but not a
      ->rebuild (f.e. PLIP).  So we need a helper function just like
      dev_hard_header() to avoid crashes.
      
      Use this helper in the one existing place where the
      header_ops->rebuild was being invoked, the neighbour code.
      
      With lots of help from Florian Westphal.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2205369a
  29. 18 12月, 2013 1 次提交
  30. 14 12月, 2013 1 次提交
  31. 13 12月, 2013 2 次提交
    • S
      net: make neigh_priv_len in struct net_device 16bit instead of 8bit · a0a9663d
      Sebastian Siewior 提交于
      neigh_priv_len is defined as u8. With all debug enabled struct
      ipoib_neigh has 200 bytes. The largest part is sk_buff_head with 96
      bytes and here the spinlock with 72 bytes.
      The size value still fits in this u8 leaving some room for more.
      
      On -RT struct ipoib_neigh put on weight and has 392 bytes. The main
      reason is sk_buff_head with 288 and the fatty here is spinlock with 192
      bytes. This does no longer fit into into neigh_priv_len and gcc
      complains.
      
      This patch changes neigh_priv_len from being 8bit to 16bit. Since the
      following element (dev_id) is 16bit followed by a spinlock which is
      aligned, the struct remains with a total size of 3200 (allmodconfig) /
      2048 (with as much debug off as possible) bytes on x86-64.
      On x86-32 the struct is 1856 (allmodconfig) / 1216 (with as much debug
      off as possible) bytes long. The numbers were gained with and without
      the patch to prove that this change does not increase the size of the
      struct.
      
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0a9663d
    • J
      net-gro: Prepare GRO stack for the upcoming tunneling support · 299603e8
      Jerry Chu 提交于
      This patch modifies the GRO stack to avoid the use of "network_header"
      and associated macros like ip_hdr() and ipv6_hdr() in order to allow
      an arbitary number of IP hdrs (v4 or v6) to be used in the
      encapsulation chain. This lays the foundation for various IP
      tunneling support (IP-in-IP, GRE, VXLAN, SIT,...) to be added later.
      
      With this patch, the GRO stack traversing now is mostly based on
      skb_gro_offset rather than special hdr offsets saved in skb (e.g.,
      skb->network_header). As a result all but the top layer (i.e., the
      the transport layer) must have hdrs of the same length in order for
      a pkt to be considered for aggregation. Therefore when adding a new
      encap layer (e.g., for tunneling), one must check and skip flows
      (e.g., by setting NAPI_GRO_CB(p)->same_flow to 0) that have a
      different hdr length.
      
      Note that unlike the network header, the transport header can and
      will continue to be set by the GRO code since there will be at
      most one "transport layer" in the encap chain.
      Signed-off-by: NH.K. Jerry Chu <hkchu@google.com>
      Suggested-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      299603e8
  32. 11 12月, 2013 1 次提交
    • Y
      tipc: remove TIPC usage of field af_packet_priv in struct net_device · 37cb0620
      Ying Xue 提交于
      TIPC is currently using the field 'af_packet_priv' in struct net_device
      as a handle to find the bearer instance associated to the given network
      device. But, by doing so it is blocking other networking cleanups, such
      as the one discussed here:
      
      http://patchwork.ozlabs.org/patch/178044/
      
      This commit removes this usage from TIPC. Instead, we introduce a new
      field, 'tipc_ptr', to the net_device structure, to serve this purpose.
      When TIPC bearer is enabled, the bearer object is associated to
      'tipc_ptr'. When a TIPC packet arrives in the recv_msg() upcall
      from a networking device, the bearer object can now be obtained from
      'tipc_ptr'. When a bearer is disabled, the bearer object is detached
      from its underlying network device by setting 'tipc_ptr' to NULL.
      
      Additionally, an RCU lock is used to protect the new pointer.
      Henceforth, the existing tipc_net_lock is used in write mode to
      serialize write accesses to this pointer, while the new RCU lock is
      applied on the read side to ensure that the pointer is 100% valid
      within its wrapped area for all readers.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Reviewed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37cb0620