1. 14 Dec, 2013 17 commits
  2. 12 Dec, 2013 23 commits
    • Ben Hutchings's avatar
      sfc: Remove dependency of PTP on having a dedicated channel · ac36baf8
      Ben Hutchings authored
      We need a dedicated channel on Siena to ensure we can match up
      the separate RX and timestamp events for each PTP packet.  We won't
      do this for EF10 as timestamps are delivered inline.
      
      Pass a channel index of 0 to MC_CMD_PTP_OP_ENABLE when there is no
      dedicated channel.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      ac36baf8
    • Ben Hutchings's avatar
    • Ben Hutchings's avatar
      sfc: Return EBUSY for filter insertion on EF10, matching Falcon/Siena · 065e64c4
      Ben Hutchings authored
      The MC firmware will return error MC_CMD_ERR_ENOSPC if filter
      insertion fails due to lack of resources.  The net driver's filter
      implementation for Falcon-architecture returns EBUSY.  They should
      behave consistently, so for EF10 change ENOSPC to EBUSY.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      065e64c4
    • Ben Hutchings's avatar
    • Ben Hutchings's avatar
      sfc: Fold efx_flush_all() into efx_stop_port() and update comments · d615c039
      Ben Hutchings authored
      efx_flush_all() is a really misleading name - it has nothing to do
      with e.g. flushing DMA queues.  Since it's called immediately after
      efx_stop_port() and is highly dependent on what that does, combine
      the two functions.
      
      Update comments to explain what this is doing a little better.
      Also update an related and erroneous comment in efx_start_port().
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      d615c039
    • Ben Hutchings's avatar
    • Edward Cree's avatar
      sfc: Log all unexpected MCDI errors · 1e0b8120
      Edward Cree authored
      Split each of efx_mcdi_rpc, efx_mcdi_rpc_finish, and efx_mcdi_rpc_async into
      a normal and a _quiet version; made the former log MCDI errors with
      netif_err (and include the raw MCDI error code), and the latter never log
      them at all.  Changed various callers; any where some errors are expected
      (but others are not) call the _quiet version and then if necessary log the
      MCDI error themselves.  Said logging is done by new efx_mcdi_display_error.
      
      Callers of efx_mcdi_rpc*_quiet functions which may want to log the error
      need to ensure that their outbuf is big enough to hold an MCDI error; to
      this end, they now use MCDI_DECLARE_BUF_OUT_OR_ERR, which always allocates
      at least 8 bytes.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      1e0b8120
    • Ben Hutchings's avatar
      sfc: Add new sensor names · 8d13a377
      Ben Hutchings authored
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      8d13a377
    • Edward Cree's avatar
    • Edward Cree's avatar
      sfc: Report units in sensor warnings · 2b216cef
      Edward Cree authored
      Add units to the "Sensor reports condition X for raw value Y" messages.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      2b216cef
    • Jon Cooper's avatar
      sfc: Correct RX dropped count for drops while interface is down · f8f3b5ae
      Jon Cooper authored
      We don't directly control RX ingress on Siena or any later
      controllers, and so we cannot prevent packets from entering the RX
      datapath while the RX queues are not set up.  This results in
      the hardware incrementing RX_NODESC_DROP_CNT, but it's not an
      error and we should not include it in error stats.
      
      When bringing an interface up or down, pull (or wait for) stats and
      count the number of packets that were dropped while the interface was
      down.  Subtract this from the reported RX dropped count.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      f8f3b5ae
    • Jon Cooper's avatar
    • Ben Hutchings's avatar
      sfc: Tighten the check for RX merged completion events · 92a04168
      Ben Hutchings authored
      The addition of RX event merging support means we don't reliably
      detect dropped RX events now.  Currently we will only detect them if
      the previous event for the RX queue had the CONT bit set.
      
      Only accept RX completion events as merged if the
      GET_CAPABILITIES_OUT_RX_BATCHING bit is set in datapath_caps (which it
      won't be for the low-latency datapath) and the CONT bit is not set on
      the event.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      92a04168
    • Jon Cooper's avatar
      sfc: Add MC BISTs to ethtool offline self test on EF10 · 74cd60a4
      Jon Cooper authored
      To run BISTs the MC goes down in to a special mode where it will only
      respond to MCDI from the testing PF, and TX, RX and event queues are
      torn down. Other PFs get a message as it goes down to tell them it's
      going down.
      
      When the other PFs get this message, they check the soft status
      register to tell when the MC has rebooted after BIST mode and they can
      start recovery.
      
      [bwh: Convert the test result to 1 or -1 as for earlier NICs]
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      74cd60a4
    • Florent Fourcot's avatar
      ipv6: fix incorrect type in declaration · 68536053
      Florent Fourcot authored
      Introduced by 1397ed35
        "ipv6: add flowinfo for tcp6 pkt_options for all cases"
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      
      V2: fix the title, add empty line after the declaration (Sergei Shtylyov
      feedbacks)
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68536053
    • 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