1. 04 1月, 2017 1 次提交
    • S
      af_packet: TX_RING support for TPACKET_V3 · 7f953ab2
      Sowmini Varadhan 提交于
      Although TPACKET_V3 Rx has some benefits over TPACKET_V2 Rx, *_v3
      does not currently have TX_RING support. As a result an application
      that wants the best perf for Tx and Rx (e.g. to handle request/response
      transacations) ends up needing 2 sockets, one with *_v2 for Tx and
      another with *_v3 for Rx.
      
      This patch enables TPACKET_V2 compatible Tx features in TPACKET_V3
      so that an application can use a single descriptor to get the benefits
      of _v3 RX_RING and _v2 TX_RING. An application may do a block-send by
      first filling up multiple frames in the Tx ring and then triggering a
      transmit. This patch only support fixed size Tx frames for TPACKET_V3,
      and requires that tp_next_offset must be zero.
      Signed-off-by: NSowmini Varadhan <sowmini.varadhan@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f953ab2
  2. 24 3月, 2015 1 次提交
  3. 30 7月, 2014 1 次提交
  4. 23 5月, 2014 1 次提交
  5. 13 3月, 2014 1 次提交
  6. 28 1月, 2014 1 次提交
  7. 14 1月, 2014 1 次提交
  8. 21 12月, 2013 1 次提交
  9. 10 12月, 2013 2 次提交
    • D
      packet: introduce PACKET_QDISC_BYPASS socket option · d346a3fa
      Daniel Borkmann 提交于
      This patch introduces a PACKET_QDISC_BYPASS socket option, that
      allows for using a similar xmit() function as in pktgen instead
      of taking the dev_queue_xmit() path. This can be very useful when
      PF_PACKET applications are required to be used in a similar
      scenario as pktgen, but with full, flexible packet payload that
      needs to be provided, for example.
      
      On default, nothing changes in behaviour for normal PF_PACKET
      TX users, so everything stays as is for applications. New users,
      however, can now set PACKET_QDISC_BYPASS if needed to prevent
      own packets from i) reentering packet_rcv() and ii) to directly
      push the frame to the driver.
      
      In doing so we can increase pps (here 64 byte packets) for
      PF_PACKET a bit:
      
        # CPUs -- QDISC_BYPASS   -- qdisc path -- qdisc path[**]
        1 CPU  ==  1,509,628 pps --  1,208,708 --  1,247,436
        2 CPUs ==  3,198,659 pps --  2,536,012 --  1,605,779
        3 CPUs ==  4,787,992 pps --  3,788,740 --  1,735,610
        4 CPUs ==  6,173,956 pps --  4,907,799 --  1,909,114
        5 CPUs ==  7,495,676 pps --  5,956,499 --  2,014,422
        6 CPUs ==  9,001,496 pps --  7,145,064 --  2,155,261
        7 CPUs == 10,229,776 pps --  8,190,596 --  2,220,619
        8 CPUs == 11,040,732 pps --  9,188,544 --  2,241,879
        9 CPUs == 12,009,076 pps -- 10,275,936 --  2,068,447
       10 CPUs == 11,380,052 pps -- 11,265,337 --  1,578,689
       11 CPUs == 11,672,676 pps -- 11,845,344 --  1,297,412
       [...]
       20 CPUs == 11,363,192 pps -- 11,014,933 --  1,245,081
      
       [**]: qdisc path with packet_rcv(), how probably most people
             seem to use it (hopefully not anymore if not needed)
      
      The test was done using a modified trafgen, sending a simple
      static 64 bytes packet, on all CPUs.  The trick in the fast
      "qdisc path" case, is to avoid reentering packet_rcv() by
      setting the RAW socket protocol to zero, like:
      socket(PF_PACKET, SOCK_RAW, 0);
      
      Tradeoffs are documented as well in this patch, clearly, if
      queues are busy, we will drop more packets, tc disciplines are
      ignored, and these packets are not visible to taps anymore. For
      a pktgen like scenario, we argue that this is acceptable.
      
      The pointer to the xmit function has been placed in packet
      socket structure hole between cached_dev and prot_hook that
      is hot anyway as we're working on cached_dev in each send path.
      
      Done in joint work together with Jesper Dangaard Brouer.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d346a3fa
    • D
      packet: fix send path when running with proto == 0 · 66e56cd4
      Daniel Borkmann 提交于
      Commit e40526cb introduced a cached dev pointer, that gets
      hooked into register_prot_hook(), __unregister_prot_hook() to
      update the device used for the send path.
      
      We need to fix this up, as otherwise this will not work with
      sockets created with protocol = 0, plus with sll_protocol = 0
      passed via sockaddr_ll when doing the bind.
      
      So instead, assign the pointer directly. The compiler can inline
      these helper functions automagically.
      
      While at it, also assume the cached dev fast-path as likely(),
      and document this variant of socket creation as it seems it is
      not widely used (seems not even the author of TX_RING was aware
      of that in his reference example [1]). Tested with reproducer
      from e40526cb.
      
       [1] http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap#Example
      
      Fixes: e40526cb ("packet: fix use after free race in send path when dev is released")
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Tested-by: NSalam Noureddine <noureddine@aristanetworks.com>
      Tested-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66e56cd4
  10. 30 8月, 2013 1 次提交
  11. 08 6月, 2013 1 次提交
  12. 25 4月, 2013 1 次提交
  13. 31 3月, 2013 1 次提交
  14. 10 11月, 2012 1 次提交
  15. 08 11月, 2012 1 次提交
  16. 24 12月, 2011 1 次提交
  17. 31 3月, 2011 1 次提交
  18. 04 8月, 2010 1 次提交
    • J
      Documentation: update broken web addresses. · 0ea6e611
      Justin P. Mattock 提交于
      Below you will find an updated version from the original series bunching all patches into one big patch
      updating broken web addresses that are located in Documentation/*
      Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult,
      the best way to deal with these is to use web.archive.org to locate these addresses that are outdated.
      Now there are also some addresses pointing to .spec files some are located, but some(after searching
      on the companies site)where still no where to be found. In this case I just changed the address
      to the company site this way the users can contact the company and they can locate them for the users.
      Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
      Signed-off-by: NThomas Weber <weber@corscience.de>
      Signed-off-by: NMike Frysinger <vapier.adi@gmail.com>
      Cc: Paulo Marques <pmarques@grupopie.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Michael Neuling <mikey@neuling.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      0ea6e611
  19. 02 6月, 2010 1 次提交
    • S
      packet_mmap: expose hw packet timestamps to network packet capture utilities · 614f60fa
      Scott McMillan 提交于
      This patch adds a setting, PACKET_TIMESTAMP, to specify the packet
      timestamp source that is exported to capture utilities like tcpdump by
      packet_mmap.
      
      PACKET_TIMESTAMP accepts the same integer bit field as
      SO_TIMESTAMPING.  However, only the SOF_TIMESTAMPING_SYS_HARDWARE and
      SOF_TIMESTAMPING_RAW_HARDWARE values are currently recognized by
      PACKET_TIMESTAMP.  SOF_TIMESTAMPING_SYS_HARDWARE takes precedence over
      SOF_TIMESTAMPING_RAW_HARDWARE if both bits are set.
      
      If PACKET_TIMESTAMP is not set, a software timestamp generated inside
      the networking stack is used (the behavior before this setting was
      added).
      Signed-off-by: NScott McMillan <scott.a.mcmillan@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      614f60fa
  20. 23 4月, 2010 1 次提交
  21. 06 2月, 2010 1 次提交
  22. 19 5月, 2009 1 次提交
  23. 27 7月, 2008 1 次提交
  24. 09 5月, 2007 1 次提交
  25. 30 11月, 2006 1 次提交
  26. 04 10月, 2006 4 次提交
  27. 01 4月, 2006 1 次提交
  28. 25 3月, 2006 1 次提交
  29. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4