1. 19 Apr, 2013 11 commits
    • Patrick McHardy's avatar
      net: add function to allocate sk_buff head without data area · 0ebd0ac5
      Patrick McHardy authored
      Add a function to allocate a sk_buff head without any data. This will
      be used by memory mapped netlink to attach data from the mmaped area
      to the skb.
      
      Additionally change skb_release_all() to check whether the skb has a
      data area to allow the skb destructor to clear the data pointer in case
      only a head has been allocated.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ebd0ac5
    • Patrick McHardy's avatar
      netlink: rename ssk to sk in struct netlink_skb_params · e32123e5
      Patrick McHardy authored
      Memory mapped netlink needs to store the receiving userspace socket
      when sending from the kernel to userspace. Rename 'ssk' to 'sk' to
      avoid confusion.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e32123e5
    • Patrick McHardy's avatar
      cd967e05
    • David S. Miller's avatar
      Merge branch '8021ad' · 447b816f
      David S. Miller authored
      Patrick McHardy says:
      
      ====================
      The following patches add support for 802.1ad (provider tagging) to the
      VLAN driver. The patchset consists of the following parts:
      
      - renaming of the NET_F_HW_VLAN feature flags to indicate that they only
        operate on CTAGs
      
      - preparation for 802.1ad VLAN filtering offload by adding a proto argument
        to the rx_{add,kill}_vid net_device_ops callbacks
      
      - preparation of the VLAN code to support multiple protocols by making the
        protocol used for tagging a property of the VLAN device and converting
        the device lookup functions accordingly
      
      - second step of preparation of the VLAN code by making the packet tagging
        functions take a protocol argument
      
      - introducation of 802.1ad support in the VLAN code, consisting mainly of
        checking for ETH_P_8021AD in a couple of places and testing the netdevice
        offload feature checks to take the protocol into account
      
      - announcement of STAG offloading capabilities in a couple of drivers for
        virtual network devices
      
      The patchset is based on net-next.git and has been tested with single and
      double tagging with and without HW acceleration (for CTAGs).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      447b816f
    • Patrick McHardy's avatar
      net: vlan: announce STAG offload capability in some drivers · 28d2b136
      Patrick McHardy authored
      - macvlan: propagate STAG filtering capabilities from underlying device
      - ifb: announce STAG tagging support in addition to CTAG tagging support
      - veth: announce STAG tagging/stripping support in addition to CTAG support
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28d2b136
    • Patrick McHardy's avatar
      net: vlan: add 802.1ad support · 8ad227ff
      Patrick McHardy authored
      Add support for 802.1ad VLAN devices. This mainly consists of checking for
      ETH_P_8021AD in addition to ETH_P_8021Q in a couple of places and check
      offloading capabilities based on the used protocol.
      
      Configuration is done using "ip link":
      
      # ip link add link eth0 eth0.1000 \
      	type vlan proto 802.1ad id 1000
      # ip link add link eth0.1000 eth0.1000.1000 \
      	type vlan proto 802.1q id 1000
      
      52:54:00:12:34:56 > 92:b1:54:28:e4:8c, ethertype 802.1Q (0x8100), length 106: vlan 1000, p 0, ethertype 802.1Q, vlan 1000, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
          20.1.0.2 > 20.1.0.1: ICMP echo request, id 3003, seq 8, length 64
      92:b1:54:28:e4:8c > 52:54:00:12:34:56, ethertype 802.1Q-QinQ (0x88a8), length 106: vlan 1000, p 0, ethertype 802.1Q, vlan 1000, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 47944, offset 0, flags [none], proto ICMP (1), length 84)
          20.1.0.1 > 20.1.0.2: ICMP echo reply, id 3003, seq 8, length 64
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ad227ff
    • Patrick McHardy's avatar
      net: vlan: add protocol argument to packet tagging functions · 86a9bad3
      Patrick McHardy authored
      Add a protocol argument to the VLAN packet tagging functions. In case of HW
      tagging, we need that protocol available in the ndo_start_xmit functions,
      so it is stored in a new field in the skb. The new field fits into a hole
      (on 64 bit) and doesn't increase the sks's size.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      86a9bad3
    • Patrick McHardy's avatar
      net: vlan: prepare for 802.1ad support · 1fd9b1fc
      Patrick McHardy authored
      Make the encapsulation protocol value a property of VLAN devices and change
      the device lookup functions to take the protocol value into account.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1fd9b1fc
    • Patrick McHardy's avatar
      net: vlan: prepare for 802.1ad VLAN filtering offload · 80d5c368
      Patrick McHardy authored
      Change the rx_{add,kill}_vid callbacks to take a protocol argument in
      preparation of 802.1ad support. The protocol argument used so far is
      always htons(ETH_P_8021Q).
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      80d5c368
    • Patrick McHardy's avatar
      net: vlan: rename NETIF_F_HW_VLAN_* feature flags to NETIF_F_HW_VLAN_CTAG_* · f646968f
      Patrick McHardy authored
      Rename the hardware VLAN acceleration features to include "CTAG" to indicate
      that they only support CTAGs. Follow up patches will introduce 802.1ad
      server provider tagging (STAGs) and require the distinction for hardware not
      supporting acclerating both.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f646968f
    • David S. Miller's avatar
      Merge branch 'intel' · c2962897
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      This series contains updates to ixgbe and igb.
      
      The ixgbe changes contains 2 patches from the community, one which is a
      fix from akepner to fix a issue where netif_running() in shutdown was
      not done under rtnl_lock.  The other community fix from Joe Perches
      cleans up #ifdef CONFIG_DEBUG_FS which is no longer necessary.  The
      last ixgbe patch, from Jacob Keller, adds support for WoL on 82559
      SFP+ LOM.
      
      The remaining patches are against igb, 10 of which were previously
      submitted in a pull request where changes were requested.
      
      The following igb patches:
       igb: Support for 100base-fx SFP
       igb: Support to read and export SFF-8472/8079 data
      are v2 based on feedback from Dan Carpenter and Ben Hutchings in
      the previous pull request.
      
      The largest set of changes are in my patch to cleanup code comments
      and whitespace to align the igb driver with the networking style of
      code comments.  While cleaning up the code comments, fixed several
      other whitespace/checkpatch.pl code formatting issues.
      
      Other notable igb patches are EEE capable devices query the PHY to
      determine what the link partner is advertising, added support for
      i354 devices and added support for spoofchk config.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2962897
  2. 18 Apr, 2013 27 commits
  3. 17 Apr, 2013 2 commits
    • David S. Miller's avatar
      Merge branch 'tipc-ipoib' · 2551c405
      David S. Miller authored
      Patrick McHardy says:
      
      ====================
      The following patchset adds support for running TIPC over InfiniBand.
      The patchset consists of three parts (+ a minor fix for the ethernet media
      type):
      
      - Preparation: removal of an the unused str2addr callback and move of the
        bcast_addr from struct tipc_media to struct tipc_bearer. This is necessary
        because InfiniBand doesn't have a fixed broadcast address like ethernet,
        so it needs to be initialized with the device's broadcast address when
        the bearer is enabled
      
      - Introduction of a TIPC InfiniBand media type. A new media type is needed
        to deal with the different address sizes
      
      - Support for ETH_P_TIPC in IPoIB
      
      Since the last posting I've addressed all feedback I received and rebased
      to the current net-next tree.
      
      I consider these patches ready for merging. Since they mainly affect TIPC
      code, I'd propose to have them either go through the TIPC tree or through
      Dave directly (not sure how TIPC patches are managed).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2551c405
    • Patrick McHardy's avatar
      IPoIB: add support for TIPC protocol · dc850b0e
      Patrick McHardy authored
      Support TIPC in the IPoIB driver. Since IPoIB now keeps track of its own
      neighbour entries and doesn't require the packet to have a dst_entry
      anymore, the only necessary changes are to:
      
      - not drop multicast TIPC packets because of the unknown ethernet type
      - handle unicast TIPC packets similar to IPv4/IPv6 unicast packets
      
      in ipoib_start_xmit().
      
      An alternative would be to remove all ethertype limitations since they're
      not necessary anymore, all TIPC needs to know about is ARP and RARP since
      it wants to always perform "path find", even if a path is already known.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc850b0e