1. 03 11月, 2015 2 次提交
  2. 13 10月, 2015 4 次提交
  3. 12 10月, 2015 1 次提交
  4. 05 10月, 2015 5 次提交
  5. 03 10月, 2015 4 次提交
  6. 02 10月, 2015 5 次提交
  7. 30 9月, 2015 2 次提交
    • V
      net: switchdev: abstract object in add/del ops · ab069002
      Vivien Didelot 提交于
      Similar to the notifier_call callback of a notifier_block, change the
      function signature of switchdev add and del operations to:
      
          int switchdev_port_obj_add/del(struct net_device *dev,
                                         enum switchdev_obj_id id, void *obj);
      
      This allows the caller to pass a specific switchdev_obj_* structure
      instead of the generic switchdev_obj one.
      
      Drivers implementation of these operations and switchdev have been
      changed accordingly.
      Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab069002
    • N
      bridge: vlan: add per-vlan struct and move to rhashtables · 2594e906
      Nikolay Aleksandrov 提交于
      This patch changes the bridge vlan implementation to use rhashtables
      instead of bitmaps. The main motivation behind this change is that we
      need extensible per-vlan structures (both per-port and global) so more
      advanced features can be introduced and the vlan support can be
      extended. I've tried to break this up but the moment net_port_vlans is
      changed and the whole API goes away, thus this is a larger patch.
      A few short goals of this patch are:
      - Extensible per-vlan structs stored in rhashtables and a sorted list
      - Keep user-visible behaviour (compressed vlans etc)
      - Keep fastpath ingress/egress logic the same (optimizations to come
        later)
      
      Here's a brief list of some of the new features we'd like to introduce:
      - per-vlan counters
      - vlan ingress/egress mapping
      - per-vlan igmp configuration
      - vlan priorities
      - avoid fdb entries replication (e.g. local fdb scaling issues)
      
      The structure is kept single for both global and per-port entries so to
      avoid code duplication where possible and also because we'll soon introduce
      "port0 / aka bridge as port" which should simplify things further
      (thanks to Vlad for the suggestion!).
      
      Now we have per-vlan global rhashtable (bridge-wide) and per-vlan port
      rhashtable, if an entry is added to a port it'll get a pointer to its
      global context so it can be quickly accessed later. There's also a
      sorted vlan list which is used for stable walks and some user-visible
      behaviour such as the vlan ranges, also for error paths.
      VLANs are stored in a "vlan group" which currently contains the
      rhashtable, sorted vlan list and the number of "real" vlan entries.
      A good side-effect of this change is that it resembles how hw keeps
      per-vlan data.
      One important note after this change is that if a VLAN is being looked up
      in the bridge's rhashtable for filtering purposes (or to check if it's an
      existing usable entry, not just a global context) then the new helper
      br_vlan_should_use() needs to be used if the vlan is found. In case the
      lookup is done only with a port's vlan group, then this check can be
      skipped.
      
      Things tested so far:
      - basic vlan ingress/egress
      - pvids
      - untagged vlans
      - undef CONFIG_BRIDGE_VLAN_FILTERING
      - adding/deleting vlans in different scenarios (with/without global ctx,
        while transmitting traffic, in ranges etc)
      - loading/removing the module while having/adding/deleting vlans
      - extracting bridge vlan information (user ABI), compressed requests
      - adding/deleting fdbs on vlans
      - bridge mac change, promisc mode
      - default pvid change
      - kmemleak ON during the whole time
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2594e906
  8. 09 9月, 2015 1 次提交
  9. 28 8月, 2015 1 次提交
  10. 11 8月, 2015 1 次提交
  11. 24 6月, 2015 1 次提交
  12. 23 6月, 2015 1 次提交
  13. 16 6月, 2015 1 次提交
    • S
      bridge: use either ndo VLAN ops or switchdev VLAN ops to install MASTER vlans · 7f109539
      Scott Feldman 提交于
      v2:
      
      Move struct switchdev_obj automatics to inner scope where there used.
      
      v1:
      
      To maintain backward compatibility with the existing iproute2 "bridge vlan"
      command, let bridge's setlink/dellink handler call into either the port
      driver's 8021q ndo ops or the port driver's bridge_setlink/dellink ops.
      
      This allows port driver to choose 8021q ops or the newer
      bridge_setlink/dellink ops when implementing VLAN add/del filtering on the
      device.  The iproute "bridge vlan" command does not need to be modified.
      
      To summarize using the "bridge vlan" command examples, we have:
      
      1) bridge vlan add|del vid VID dev DEV
      
      Here iproute2 sets MASTER flag.  Bridge's bridge_setlink/dellink is called.
      Vlan is set on bridge for port.  If port driver implements ndo 8021q ops,
      call those to port driver can install vlan filter on device.  Otherwise, if
      port driver implements bridge_setlink/dellink ops, call those to install
      vlan filter to device.  This option only works if port is bridged.
      
      2) bridge vlan add|del vid VID dev DEV master
      
      Same as 1)
      
      3) bridge vlan add|del vid VID dev DEV self
      
      Bridge's bridge_setlink/dellink isn't called.  Port driver's
      bridge_setlink/dellink is called, if implemented.  This option works if
      port is bridged or not.  If port is not bridged, a VLAN can still be
      added/deleted to device filter using this variant.
      
      4) bridge vlan add|del vid VID dev DEV master self
      
      This is a combination of 1) and 3), but will only work if port is bridged.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f109539
  14. 14 1月, 2015 1 次提交
  15. 22 11月, 2014 1 次提交
  16. 06 10月, 2014 3 次提交
  17. 16 9月, 2014 1 次提交
  18. 14 9月, 2014 2 次提交
    • V
      bridge: Allow clearing of pvid and untagged bitmap · 635126b7
      Vlad Yasevich 提交于
      Currently, it is possible to modify the vlan filter
      configuration to add pvid or untagged support.
      For example:
        bridge vlan add vid 10 dev eth0
        bridge vlan add vid 10 dev eth0 untagged pvid
      
      The second statement will modify vlan 10 to
      include untagged and pvid configuration.
      However, it is currently impossible to go backwards
        bridge vlan add vid 10 dev eth0 untagged pvid
        bridge vlan add vid 10 dev eth0
      
      Here nothing happens.  This patch correct this so
      that any modifiers not supplied are removed from
      the configuration.
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      635126b7
    • V
      bridge: Check if vlan filtering is enabled only once. · 20adfa1a
      Vlad Yasevich 提交于
      The bridge code checks if vlan filtering is enabled on both
      ingress and egress.   When the state flip happens, it
      is possible for the bridge to currently be forwarding packets
      and forwarding behavior becomes non-deterministic.  Bridge
      may drop packets on some interfaces, but not others.
      
      This patch solves this by caching the filtered state of the
      packet into skb_cb on ingress.  The skb_cb is guaranteed to
      not be over-written between the time packet entres bridge
      forwarding path and the time it leaves it.  On egress, we
      can then check the cached state to see if we need to
      apply filtering information.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20adfa1a
  19. 12 8月, 2014 1 次提交
    • V
      net: Always untag vlan-tagged traffic on input. · 0d5501c1
      Vlad Yasevich 提交于
      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)
          10.0.100.1.58545 > 10.0.100.10.ircu-2: 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)
          10.0.100.1.58545 > 10.0.100.10.ircu-2: 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: NVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d5501c1
  20. 06 8月, 2014 1 次提交
  21. 12 6月, 2014 1 次提交
    • T
      bridge: Support 802.1ad vlan filtering · 204177f3
      Toshiaki Makita 提交于
      This enables us to change the vlan protocol for vlan filtering.
      We come to be able to filter frames on the basis of 802.1ad vlan tags
      through a bridge.
      
      This also changes br->group_addr if it has not been set by user.
      This is needed for an 802.1ad bridge.
      (See IEEE 802.1Q-2011 8.13.5.)
      
      Furthermore, this sets br->group_fwd_mask_required so that an 802.1ad
      bridge can forward the Nearest Customer Bridge group addresses except
      for br->group_addr, which should be passed to higher layer.
      
      To change the vlan protocol, write a protocol in sysfs:
      # echo 0x88a8 > /sys/class/net/br0/bridge/vlan_protocol
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      204177f3