1. 02 1月, 2014 3 次提交
  2. 01 1月, 2014 1 次提交
  3. 27 12月, 2013 1 次提交
  4. 23 12月, 2013 1 次提交
  5. 19 12月, 2013 2 次提交
  6. 16 12月, 2013 1 次提交
  7. 14 12月, 2013 1 次提交
  8. 13 12月, 2013 2 次提交
    • F
      ipv6: fix incorrect type in declaration · 68536053
      Florent Fourcot 提交于
      Introduced by 1397ed35
        "ipv6: add flowinfo for tcp6 pkt_options for all cases"
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      
      V2: fix the title, add empty line after the declaration (Sergei Shtylyov
      feedbacks)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68536053
    • J
      net-gro: Prepare GRO stack for the upcoming tunneling support · 299603e8
      Jerry Chu 提交于
      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: NH.K. Jerry Chu <hkchu@google.com>
      Suggested-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      299603e8
  9. 12 12月, 2013 1 次提交
    • J
      ipv6: router reachability probing · 7e980569
      Jiri Benc 提交于
      RFC 4191 states in 3.5:
      
         When a host avoids using any non-reachable router X and instead sends
         a data packet to another router Y, and the host would have used
         router X if router X were reachable, then the host SHOULD probe each
         such router X's reachability by sending a single Neighbor
         Solicitation to that router's address.  A host MUST NOT probe a
         router's reachability in the absence of useful traffic that the host
         would have sent to the router if it were reachable.  In any case,
         these probes MUST be rate-limited to no more than one per minute per
         router.
      
      Currently, when the neighbour corresponding to a router falls into
      NUD_FAILED, it's never considered again. Introduce a new rt6_nud_state
      value, RT6_NUD_FAIL_PROBE, which suggests the route should not be used but
      should be probed with a single NS. The probe is ratelimited by the existing
      code. To better distinguish meanings of the failure values, rename
      RT6_NUD_FAIL_SOFT to RT6_NUD_FAIL_DO_RR.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e980569
  10. 11 12月, 2013 4 次提交
  11. 10 12月, 2013 10 次提交
  12. 07 12月, 2013 4 次提交
  13. 06 12月, 2013 1 次提交
  14. 03 12月, 2013 3 次提交
  15. 01 12月, 2013 1 次提交
  16. 29 11月, 2013 2 次提交
  17. 24 11月, 2013 2 次提交