1. 16 7月, 2015 2 次提交
  2. 06 5月, 2015 1 次提交
    • 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
  3. 01 4月, 2015 1 次提交
  4. 12 2月, 2015 1 次提交
  5. 10 12月, 2014 1 次提交
  6. 30 11月, 2014 1 次提交
  7. 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