1. 05 1月, 2009 3 次提交
  2. 30 12月, 2008 2 次提交
  3. 26 12月, 2008 4 次提交
  4. 19 12月, 2008 1 次提交
  5. 16 12月, 2008 3 次提交
    • I
      ipmr: merge common code · b1879204
      Ilpo Järvinen 提交于
      Also removes redundant skb->len < x check which can't
      be true once pskb_may_pull(skb, x) succeeded.
      
      $ diff-funcs pim_rcv ipmr.c ipmr.c pim_rcv_v1
        --- ipmr.c:pim_rcv()
        +++ ipmr.c:pim_rcv_v1()
      @@ -1,22 +1,27 @@
      -static int pim_rcv(struct sk_buff * skb)
      +int pim_rcv_v1(struct sk_buff * skb)
       {
      -	struct pimreghdr *pim;
      +	struct igmphdr *pim;
       	struct iphdr   *encap;
       	struct net_device  *reg_dev = NULL;
      
       	if (!pskb_may_pull(skb, sizeof(*pim) + sizeof(*encap)))
       		goto drop;
      
      -	pim = (struct pimreghdr *)skb_transport_header(skb);
      -	if (pim->type != ((PIM_VERSION<<4)|(PIM_REGISTER)) ||
      -	    (pim->flags&PIM_NULL_REGISTER) ||
      -	    (ip_compute_csum((void *)pim, sizeof(*pim)) != 0 &&
      -	     csum_fold(skb_checksum(skb, 0, skb->len, 0))))
      +	pim = igmp_hdr(skb);
      +
      +	if (!mroute_do_pim ||
      +	    skb->len < sizeof(*pim) + sizeof(*encap) ||
      +	    pim->group != PIM_V1_VERSION || pim->code != PIM_V1_REGISTER)
       		goto drop;
      
      -	/* check if the inner packet is destined to mcast group */
       	encap = (struct iphdr *)(skb_transport_header(skb) +
      -				 sizeof(struct pimreghdr));
      +				 sizeof(struct igmphdr));
      +	/*
      +	   Check that:
      +	   a. packet is really destinted to a multicast group
      +	   b. packet is not a NULL-REGISTER
      +	   c. packet is not truncated
      +	 */
       	if (!ipv4_is_multicast(encap->daddr) ||
       	    encap->tot_len == 0 ||
       	    ntohs(encap->tot_len) + sizeof(*pim) > skb->len)
      @@ -40,9 +45,9 @@
       	skb->ip_summed = 0;
       	skb->pkt_type = PACKET_HOST;
       	dst_release(skb->dst);
      +	skb->dst = NULL;
       	reg_dev->stats.rx_bytes += skb->len;
       	reg_dev->stats.rx_packets++;
      -	skb->dst = NULL;
       	nf_reset(skb);
       	netif_rx(skb);
       	dev_put(reg_dev);
      
      $ codiff net/ipv4/ipmr.o.old net/ipv4/ipmr.o.new
      
      net/ipv4/ipmr.c:
        pim_rcv_v1 | -283
        pim_rcv    | -284
       2 functions changed, 567 bytes removed
      
      net/ipv4/ipmr.c:
        __pim_rcv | +307
       1 function changed, 307 bytes added
      
      net/ipv4/ipmr.o.new:
       3 functions changed, 307 bytes added, 567 bytes removed, diff: -260
      
      (Tested on x86_64).
      
      It seems that pimlen arg could be left out as well and
      eq-sizedness of structs trapped with BUILD_BUG_ON but
      I don't think that's more than a cosmetic flaw since there
      aren't that many args anyway.
      
      Compile tested.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b1879204
    • H
      tcp: Add GRO support · bf296b12
      Herbert Xu 提交于
      This patch adds the TCP-specific portion of GRO.  The criterion for
      merging is extremely strict (the TCP header must match exactly apart
      from the checksum) so as to allow refragmentation.  Otherwise this
      is pretty much identical to LRO, except that we support the merging
      of ECN packets.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf296b12
    • H
      ipv4: Add GRO infrastructure · 73cc19f1
      Herbert Xu 提交于
      This patch adds GRO support for IPv4.
      
      The criteria for merging is more stringent than LRO, in particular,
      we require all fields in the IP header to be identical except for
      the length, ID and checksum.  In addition, the ID must form an
      arithmetic sequence with a difference of one.
      
      The ID requirement might seem overly strict, however, most hardware
      TSO solutions already obey this rule.  Linux itself also obeys this
      whether GSO is in use or not.
      
      In future we could relax this rule by storing the IDs (or rather
      making sure that we don't drop them when pulling the aggregate
      skb's tail).
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73cc19f1
  6. 15 12月, 2008 2 次提交
  7. 09 12月, 2008 1 次提交
    • D
      tcp: tcp_vegas cong avoid fix · 8d3a564d
      Doug Leith 提交于
      This patch addresses a book-keeping issue in tcp_vegas.c.  At present
      tcp_vegas does separate book-keeping of cwnd based on packet sequence
      numbers.  A mismatch can develop between this book-keeping and
      tp->snd_cwnd due, for example, to delayed acks acking multiple
      packets.  When vegas transitions to reno operation (e.g. following
      loss), then this mismatch leads to incorrect behaviour (akin to a cwnd
      backoff).  This seems mostly to affect operation at low cwnds where
      delayed acking can lead to a significant fraction of cwnd being
      covered by a single ack, leading to the book-keeping mismatch.  This
      patch modifies the congestion avoidance update to avoid the need for
      separate book-keeping while leaving vegas congestion avoidance
      functionally unchanged.  A secondary advantage of this modification is
      that the use of fixed-point (via V_PARAM_SHIFT) and 64 bit arithmetic
      is no longer necessary, simplifying the code.
      
      Some example test measurements with the patched code (confirming no functional
      change in the congestion avoidance algorithm) can be seen at:
      
      http://www.hamilton.ie/doug/vegaspatch/Signed-off-by: NDoug Leith <doug.leith@nuim.ie>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d3a564d
  8. 06 12月, 2008 10 次提交
  9. 05 12月, 2008 1 次提交
    • D
      tcp: tcp_vegas ssthresh bug fix · a6af2d6b
      Doug Leith 提交于
      This patch fixes a bug in tcp_vegas.c.  At the moment this code leaves
      ssthresh untouched.  However, this means that the vegas congestion
      control algorithm is effectively unable to reduce cwnd below the
      ssthresh value (if the vegas update lowers the cwnd below ssthresh,
      then slow start is activated to raise it back up).  One example where
      this matters is when during slow start cwnd overshoots the link
      capacity and a flow then exits slow start with ssthresh set to a value
      above where congestion avoidance would like to adjust it.
      Signed-off-by: NDoug Leith <doug.leith@nuim.ie>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a6af2d6b
  10. 04 12月, 2008 3 次提交
    • B
      net: /proc/net/ip_mr_cache, display Iif as a signed short · 999890b2
      Benjamin Thery 提交于
      Today, iproute2 fails to show multicast forwarding unresolved cache
      entries while scanning /proc/net/ip_mr_cache.
      
      Indeed, it expects to see -1 in 'Iif' column to identify unresolved
      entries but the kernel outputs 65535. It's a signed/unsigned issue:
      
      'Iif', the source interface, is retrieved from member mfc_parent in
      struct mfc_cache. mfc_parent is a vifi_t: unsigned short, but is
      displayed in ipmr_mfc_seq_show() as "%-3d", signed integer.
      
      In unresolevd entries, the 65535 value (0xFFFF) comes from this define:
      #define ALL_VIFS    ((vifi_t)(-1))
      
      That may explains why the guy who added support for this in iproute2
      thought a -1 should be expected.
      
      I don't know if this must be fixed in kernel or in iproute2. Who is
      right? What is the correct API? How was it designed originally?
      
      I let you decide if it should goes in the kernel or be fixed in iproute2.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      999890b2
    • B
      net: fix /proc/net/ip_mr_cache display - V2 · 1ea472e2
      Benjamin Thery 提交于
      /proc/net/ip_mr_cache and /proc/net/ip6_mr_cache displays garbage when
      showing unresolved mfc_cache entries.
      
      [root@qemu tests]# cat /proc/net/ip_mr_cache
      Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
      014C00EF 010014AC 1         10    10050        0  2:1    3:1
      024C00EF 010014AC 65535      514        2 -559067475
      
      The first line is correct. It is a resolved cache entry, 10 packets used it...
      The second line represents an unresolved entry, and the columns Pkts(4th),
      Bytes(5th) and Wrong(6th) just show garbage.
      
      In struct mfc_cache, there's an union to store data for resolved and
      unresolved cases. And what ipmr_mfc_seq_show() is printing in these 
      columns for the unresolved entries is some bytes from mfc_cache.mfc_un.res.
      Bad.
      (eg. In our case -559067475 is in fact 0xdead4ead which is the spinlock
      magic from mfc_cache.mfc_un.unres.unresolved.lock.magic).
      
      This patch replaces the garbage data written in these columns for the
      unresolved entries by '0' (zeros) which is more correct.
      This change doesn't break the ABI.
      
      Also, mfc->mfc_un.res.pkt, mfc->mfc_un.res.bytes, mfc->mfc_un.res.wrong_if
      are unsigned long.
      
      It applies on top of net-next-2.6.
      
      The patch for net-2.6 is slightly different because of the NIP6_FMT to
      %pI6 conversion that was made in the seq_printf.
      
      Changelog:
      ==========
      V2:
      * Instead of breaking the ABI by suppressing the columns that have no
        meaning for unresolved entries, fill them with 0 values.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ea472e2
    • I
      tcp: make urg+gso work for real this time · f8269a49
      Ilpo Järvinen 提交于
      I should have noticed this earlier... :-) The previous solution
      to URG+GSO/TSO will cause SACK block tcp_fragment to do zig-zig
      patterns, or even worse, a steep downward slope into packet
      counting because each skb pcount would be truncated to pcount
      of 2 and then the following fragments of the later portion would
      restore the window again.
      
      Basically this reverts "tcp: Do not use TSO/GSO when there is
      urgent data" (33cf71ce). It also removes some unnecessary code
      from tcp_current_mss that didn't work as intented either (could
      be that something was changed down the road, or it might have
      been broken since the dawn of time) because it only works once
      urg is already written while this bug shows up starting from
      ~64k before the urg point.
      
      The retransmissions already are split to mss sized chunks, so
      only new data sending paths need splitting in case they have
      a segment otherwise suitable for gso/tso. The actually check
      can be improved to be more narrow but since this is late -rc
      already, I'll postpone thinking the more fine-grained things.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8269a49
  11. 02 12月, 2008 1 次提交
  12. 26 11月, 2008 9 次提交