1. 12 Dec, 2013 12 commits
    • Olof Johansson's avatar
      net: eth: 8390: remove section warning in etherh.c · 335802d1
      Olof Johansson authored
      Commit c45f812f ('8390 : Replace ei_debug with msg_enable/NETIF_MSG_*
      feature') ended up moving the printout of version[] from something that
      will be compiled out due to defines, to something that is now evaluated
      at runtime.
      
      That means that what always used to be an access to an __initdata string
      from non-__init code started showing up as a section mismatch when it
      didn't before.
      
      All other 8390 versions skip __initdata on the version string, and
      starting to annotate the whole chain of callers with __init seems like
      more churn than it's worth on this driver, so remove it from etherh.c as well.
      
      Fixes: c45f812f ('8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature')
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      335802d1
    • Jerry Chu's avatar
      net-gro: Prepare GRO stack for the upcoming tunneling support · 299603e8
      Jerry Chu authored
      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: default avatarH.K. Jerry Chu <hkchu@google.com>
      Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      299603e8
    • David S. Miller's avatar
      Merge branch 'macvtap_capture' · a46dc748
      David S. Miller authored
      Vlad Yasevich says:
      
      ====================
      Add packet capture support on macvtap device
      
      Change from RFC:
        - moved to the rx_handler approach.
      
      This series adds support for packet capturing on macvtap device.
      The initial approach was to simply export the capturing code as
      a function from the core network.  While simple, it was not
      a very architecturally clean approach.
      
      The new appraoch is to provide macvtap with its rx_handler which can
      is attached to the macvtap device itself.   Macvlan will simply requeue
      the packet with an updated skb->dev.  BTW, macvlan layer already does this
      for macvlan devices.  So, now macvtap and macvlan have almost the
      same exact input path.
      
      I've toyed with short-circuting the input path for macvtap by returning
      RX_HANDLER_ANOTHER, but that just made the code more complicated and
      didn't provide any kind of measurable gain (at least according to
      netperf and perf runs on the host).
      
      To see if there was a performance regression, I ran 1, 2 and 4 netperf
      STREAM and MAERTS tests agains the VM from both remote host and another
      guest on the same system.   The command ran was
          netperf -H $host -t $test -l 20 -i 10 -I 95 -c -C
      
      The numbers I was getting with the new code were consistently very
      slightly (1-2%) better then the old code.  I don't consider this
      an improvement, but it's not a regression! :)
      
      Running 'perf record' on the host didn't show any new hot spots
      and cpu utilization stayed about the same.  This was better
      then I expected from simply looking at the code.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a46dc748
    • Vlad Yasevich's avatar
      macvlan: Remove custom recieve and forward handlers · 2f6a1b66
      Vlad Yasevich authored
      Since now macvlan and macvtap use the same receive and
      forward handlers, we can remove them completely and use
      netif_rx and dev_forward_skb() directly.
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f6a1b66
    • Vlad Yasevich's avatar
      macvtap: Add support of packet capture on macvtap device. · 6acf54f1
      Vlad Yasevich authored
      Macvtap device currently doesn not allow a user to capture
      traffic on due to the fact that it steals the packets
      from the network stack before the skb->dev is set correctly
      on the receive side, and that use uses macvlan transmit
      path directly on the send side.  As a result, we never
      get a change to give traffic to the taps while the correct
      device is set in the skb.
      
      This patch makes macvtap device behave almost exaclty like
      macvlan.  On the send side, we switch to using dev_queue_xmit().
      On the receive side, to deliver packets to macvtap, we now
      use netif_rx and dev_forward_skb just like macvlan.  The only
      differnce now is that macvtap has its own rx_handler which is
      attached to the macvtap netdev.  It is here that we now steal
      the packet and provide it to the socket.
      
      As a result, we can now capture traffic on the macvtap device:
         tcpdump -i macvtap0
      
      It also gives us the abilit to add tc actions to the macvtap
      device and actually utilize different bandwidth management
      queues on output.
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6acf54f1
    • David S. Miller's avatar
      Merge branch 'bpf' · 70f56132
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      bpf/filter updates
      
      This set adds just two minimal helper tools that complement the
      already available bpf_jit_disasm and complete BPF tooling; plus
      it adds and an extensive documentation update of filter.txt.
      
      Please see individual descriptions for details.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      70f56132
    • Daniel Borkmann's avatar
      filter: doc: improve BPF documentation · 7924cd5e
      Daniel Borkmann authored
      This patch significantly updates the BPF documentation and describes
      its internal architecture, Linux extensions, and handling of the
      kernel's BPF and JIT engine, plus documents how development can be
      facilitated with the help of bpf_dbg, bpf_asm, bpf_jit_disasm.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7924cd5e
    • Daniel Borkmann's avatar
      filter: bpf_asm: add minimal bpf asm tool · 3f356385
      Daniel Borkmann authored
      There are a couple of valid use cases for a minimal low-level bpf asm
      like tool, for example, using/linking to libpcap is not an option, the
      required BPF filters use Linux extensions that are not supported by
      libpcap's compiler, a filter might be more complex and not cleanly
      implementable with libpcap's compiler, particular filter codes should
      be optimized differently than libpcap's internal BPF compiler does,
      or for security audits of emitted BPF JIT code for prepared set of BPF
      instructions resp. BPF JIT compiler development in general.
      
      Then, in such cases writing such a filter in low-level syntax can be
      an good alternative, for example, xt_bpf and cls_bpf users might have
      requirements that could result in more complex filter code, or one that
      cannot be expressed with libpcap (e.g. different return codes in
      cls_bpf for flowids on various BPF code paths).
      
      Moreover, BPF JIT implementors may wish to manually write test cases
      in order to verify the resulting JIT image, and thus need low-level
      access to BPF code generation as well. Therefore, complete the available
      toolchain for BPF with this small bpf_asm helper tool for the tools/net/
      directory. These 3 complementary minimal helper tools round up and
      facilitate BPF development.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f356385
    • Daniel Borkmann's avatar
      filter: bpf_dbg: add minimal bpf debugger · fd981e3c
      Daniel Borkmann authored
      This patch adds a minimal BPF debugger that "emulates" the kernel's
      BPF engine (w/o extensions) and allows for single stepping (forwards
      and backwards through BPF code) or running with >=1 breakpoints through
      selected or all packets from a pcap file with a provided user filter
      in order to facilitate verification of a BPF program. When a breakpoint
      is being hit, it dumps all register contents, decoded instructions and
      in case of branches both decoded branch targets as well as other useful
      information.
      
      Having this facility is in particular useful to verify BPF programs
      against given test traffic *before* attaching to a live system.
      
      With the general availability of cls_bpf, xt_bpf, socket filters,
      team driver and e.g. PTP code, all BPF users, quite often a single
      more complex BPF program is being used. Reasons for a more complex
      BPF program are primarily to optimize execution time for making a
      verdict when multiple simple BPF programs are combined into one in
      order to prevent parsing same headers multiple times. In particular,
      for cls_bpf that can have various return paths for encoding flowids,
      and xt_bpf to come to a fw verdict this can be the case.
      
      Therefore, as this can result in more complex and harder to debug
      code, it would be very useful to have this minimal tool for testing
      purposes. It can also be of help for BPF JIT developers as filters
      are "test attached" to the kernel on a temporary socket thus
      triggering a JIT image dump when enabled. The tool uses an interactive
      libreadline shell with auto-completion and history support.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd981e3c
    • Olof Johansson's avatar
      net: eth: cpsw: 64-bit phys_addr_t and sparse cleanup · 1a3b5056
      Olof Johansson authored
      Minor fix for printk format of a phys_addr_t, and the switch of two local
      functions to static since they're not used outside of the file.
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a3b5056
    • Olof Johansson's avatar
      net: eth: davinci_cpdma: Mark a local variable static · df784160
      Olof Johansson authored
      Only used locally. Found by sparse.
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df784160
    • Olof Johansson's avatar
      net: eth: davinci_cpdma: 64-bit phys/dma_addr_t cleanup · c767db51
      Olof Johansson authored
      Silences the below warnings when building with ARM_LPAE enabled, which
      gives longer dma_addr_t by default:
      
      drivers/net/ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
      drivers/net/ethernet/ti/davinci_cpdma.c:182:3: warning: passing argument 3 of 'dma_alloc_attrs' from incompatible pointer type [enabled by default]
      drivers/net/ethernet/ti/davinci_cpdma.c: In function 'desc_phys':
      drivers/net/ethernet/ti/davinci_cpdma.c:222:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
      drivers/net/ethernet/ti/davinci_cpdma.c:223:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c767db51
  2. 11 Dec, 2013 28 commits