1. 10 6月, 2016 1 次提交
  2. 29 4月, 2016 1 次提交
  3. 18 3月, 2016 1 次提交
  4. 26 2月, 2016 1 次提交
  5. 22 2月, 2016 2 次提交
  6. 05 2月, 2016 1 次提交
    • M
      ipvlan: inherit MTU from master device · 296d4856
      Mahesh Bandewar 提交于
      When we create IPvlan slave; we use ether_setup() and that
      sets up default MTU to 1500 while the master device may have
      lower / different MTU. Any subsequent changes to the masters'
      MTU are reflected into the slaves' MTU setting. However if those
      don't happen (most likely scenario), the slaves' MTU stays at
      1500 which could be bad.
      
      This change adds code to inherit MTU from the master device
      instead of using the default value during the link initialization
      phase.
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Tim Hockins <thockins@google.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      296d4856
  7. 16 12月, 2015 1 次提交
    • T
      net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK · a188222b
      Tom Herbert 提交于
      The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
      set of features for offloading all checksums. This is a mask of the
      checksum offload related features bits. It is incorrect to set both
      NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
      features of a device.
      
      This patch:
        - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
          NETIF_F_ALL_CSUM is being used as a mask).
        - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
          use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a188222b
  8. 19 8月, 2015 1 次提交
  9. 16 7月, 2015 4 次提交
  10. 06 5月, 2015 2 次提交
    • M
      ipvlan: Always set broadcast bit in multicast filter · f631c44b
      Mahesh Bandewar 提交于
      Earlier tricks of setting broadcast bit only when IPv4 address is added
      onto interface are not good enough especially when autoconf comes in play.
      Setting them on always is performance drag but now that multicast /
      broadcast is not processed in fast-path; enabling broadcast will let
      autoconf work correctly without affecting performance characteristics of
      the device.
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f631c44b
    • M
      ipvlan: Defer multicast / broadcast processing to a work-queue · ba35f858
      Mahesh Bandewar 提交于
      Processing multicast / broadcast in fast path is performance draining
      and having more links means more cloning and bringing performance
      down further.
      
      Broadcast; in particular, need to be given to all the virtual links.
      Earlier tricks of enabling broadcast bit for IPv4 only interfaces are not
      really working since it fails autoconf. Which means enabling broadcast
      for all the links if protocol specific hacks do not have to be added into
      the driver.
      
      This patch defers all (incoming as well as outgoing) multicast traffic to
      a work-queue leaving only the unicast traffic in the fast-path. Now if we
      need to apply any additional tricks to further reduce the impact of this
      (multicast / broadcast) type of traffic, it can be implemented while
      processing this work without affecting the fast-path.
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba35f858
  11. 03 4月, 2015 1 次提交
  12. 01 4月, 2015 3 次提交
  13. 03 3月, 2015 1 次提交
  14. 10 12月, 2014 2 次提交
  15. 06 12月, 2014 1 次提交
  16. 27 11月, 2014 1 次提交
    • M
      ipvlan: fix sparse warnings · 92c7b0de
      Mahesh Bandewar 提交于
      Fix sparse warnings reported by kbuild robot
      
      drivers/net/ipvlan/ipvlan_main.c:172:13: warning: symbol 'ipvlan_start_xmit' was not declared. Should it be static?
      drivers/net/ipvlan/ipvlan_main.c:256:33: warning: incorrect type in initializer (different address spaces)
      drivers/net/ipvlan/ipvlan_main.c:256:33:    expected void const [noderef] <asn:3>*__vpp_verify
      drivers/net/ipvlan/ipvlan_main.c:256:33:    got struct ipvl_pcpu_stats *<noident>
      drivers/net/ipvlan/ipvlan_main.c:544:5: warning: symbol 'ipvlan_link_register' was not declared. Should it be static
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      92c7b0de
  17. 25 11月, 2014 1 次提交
    • M
      ipvlan: Initial check-in of the IPVLAN driver. · 2ad7bf36
      Mahesh Bandewar 提交于
      This driver is very similar to the macvlan driver except that it
      uses L3 on the frame to determine the logical interface while
      functioning as packet dispatcher. It inherits L2 of the master
      device hence the packets on wire will have the same L2 for all
      the packets originating from all virtual devices off of the same
      master device.
      
      This driver was developed keeping the namespace use-case in
      mind. Hence most of the examples given here take that as the
      base setup where main-device belongs to the default-ns and
      virtual devices are assigned to the additional namespaces.
      
      The device operates in two different modes and the difference
      in these two modes in primarily in the TX side.
      
      (a) L2 mode : In this mode, the device behaves as a L2 device.
      TX processing upto L2 happens on the stack of the virtual device
      associated with (namespace). Packets are switched after that
      into the main device (default-ns) and queued for xmit.
      
      RX processing is simple and all multicast, broadcast (if
      applicable), and unicast belonging to the address(es) are
      delivered to the virtual devices.
      
      (b) L3 mode : In this mode, the device behaves like a L3 device.
      TX processing upto L3 happens on the stack of the virtual device
      associated with (namespace). Packets are switched to the
      main-device (default-ns) for the L2 processing. Hence the routing
      table of the default-ns will be used in this mode.
      
      RX processins is somewhat similar to the L2 mode except that in
      this mode only Unicast packets are delivered to the virtual device
      while main-dev will handle all other packets.
      
      The devices can be added using the "ip" command from the iproute2
      package -
      
      	ip link add link <master> <virtual> type ipvlan mode [ l2 | l3 ]
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Laurent Chavey <chavey@google.com>
      Cc: Tim Hockin <thockin@google.com>
      Cc: Brandon Philips <brandon.philips@coreos.com>
      Cc: Pavel Emelianov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2ad7bf36