11 Oct, 2007

40 commits

  • Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville
    Signed-off-by: David S. Miller

    Johannes Berg
     
  • Signed-off-by: David S. Miller

    David S. Miller
     
  • There's no reason to clear the sacktag skb hint when small part
    of the rexmit queue changes. Account changes (if any) instead when
    fragmenting/collapsing. RTO/FRTO do not touch SACKED_ACKED bits so
    no need to discard SACK tag hint at all.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     
  • Most of the description that follows comes from my mail to
    netdev (some editing done):

    Main obstacle to FRTO use is its deployment as it has to be on
    the sender side where as wireless link is often the receiver's
    access link. Take initiative on behalf of unlucky receivers and
    enable it by default in future Linux TCP senders. Also IETF
    seems to interested in advancing FRTO from experimental [1].

    How does FRTO help?
    ===================

    FRTO detects spurious RTOs and avoids a number of unnecessary
    retransmissions and a couple of other problems that can arise
    due to incorrect guess made at RTO (i.e., that segments were
    lost when they actually got delayed which is likely to occur
    e.g. in wireless environments with link-layer retransmission).
    Though FRTO cannot prevent the first (potentially unnecessary)
    retransmission at RTO, I suspect that it won't cost that much
    even if you have to pay for each bit (won't be that high
    percentage out of all packets after all :-)). However, usually
    when you have a spurious RTO, not only the first segment
    unnecessarily retransmitted but the *whole window*. It goes like
    this: all cumulative ACKs got delayed due to in-order delivery,
    then TCP will actually send 1.5*original cwnd worth of data in
    the RTO's slow-start when the delayed ACKs arrive (basically the
    original cwnd worth of it unnecessarily). In case one is
    interested in minimizing unnecessary retransmissions e.g. due to
    cost, those rexmissions must never see daylight. Besides, in the
    worst case the generated burst overloads the bottleneck buffers
    which is likely to significantly delay the further progress of
    the flow. In case of ll rexmissions, ACK compression often
    occurs at the same time making the burst very "sharp edged" (in
    that case TCP often loses most of the segments above high_seq
    => very bad performance too). When FRTO is enabled, those
    unnecessary retransmissions are fully avoided except for the
    first segment and the cwnd behavior after detected spurious RTO
    is determined by the response (one can tune that by sysctl).

    Basic version (non-SACK enhanced one), FRTO can fail to detect
    spurious RTO as spurious and falls back to conservative
    behavior. ACK lossage is much less significant than reordering,
    usually the FRTO can detect spurious RTO if at least 2
    cumulative ACKs from original window are preserved (excluding
    the ACK that advances to high_seq). With SACK-enhanced version,
    the detection is quite robust.

    FRTO should remove the need to set a high lower bound for the
    RTO estimator due to delay spikes that occur relatively common
    in some environments (esp. in wireless/cellular ones).

    [1] http://www1.ietf.org/mail-archive/web/tcpm/current/msg02862.html

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     
  • Since the SACK enhanced FRTO was added, the code has been
    under test numerous times so remove "experimental" claim
    from the documentation. Also be a bit more verbose about
    the usage.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     
  • Basically this change enables it, previously other undo_marker
    users were left with nothing. Reverse undo_marker logic
    completely to get it set right in CA_Loss. On the other hand,
    when spurious RTO is detected, clear it. Clearing might be too
    heavy for some scenarios but seems safe enough starting point
    for now and shouldn't have much effect except in majority of
    cases (if in any).

    By adding a new FLAG_ we avoid looping through write_queue when
    RTO occurs.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     
  • Implements following cleanups:
    - Comment re-placement (CodingStyle)
    - tcp_tso_acked() local (wrapper-like) variable removal
    (readability)
    - __-types removed (IMHO they make local variables jumpy looking
    and just was space)
    - acked -> flag (naming conventions elsewhere in TCP code)
    - linebreak adjustments (readability)
    - nested if()s combined (reduced indentation)
    - clarifying newlines added

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     
  • The accounting code is pretty much the same, so it's a shame
    we do it in two places.

    I'm not too sure if added fully_acked check in MTU probing is
    really what we want perhaps the added end_seq could be used in
    the after() comparison.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     
  • In addition, fix its function comment spacing.

    Signed-off-by: Ilpo Järvinen

    Ilpo Järvinen
     
  • Substraction for fackets_out is unconditional when snd_una
    advances, thus there's no need to do it inside the loop. Just
    make sure correct bounds are honored.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     
  • In general, it should not be necessary to call tcp_fragment for
    already SACKed skbs, but it's better to be safe than sorry. And
    indeed, it can be called from sacktag when a DSACK arrives or
    some ACK (with SACK) reordering occurs (sacktag could be made
    to avoid the call in the latter case though I'm not sure if it's
    worth of the trouble and added complexity to cover such marginal
    case).

    The collapse case has return for SACKED_ACKED case earlier, so
    just WARN_ON if internal inconsistency is detected for some
    reason.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: David S. Miller

    Ilpo Järvinen
     
  • The remaining warning in phy.c will be fixed later.

    Signed-off-by: Michael Buesch
    Signed-off-by: David S. Miller

    Michael Buesch
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Note: we still have several fishy areas - mcast filter
    and vlan handling.

    Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • amd8111e_calc_coalesce() ends up with insane values of tx_data_rate since
    ->tx_bytes increments missing conversion from little- to host-endian

    Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Layout of opts2 is
    : MSB(vlan_tag) : LSB(vlan_tag) : flags : 0 :
    regardless of the host endianness. On little-endian
    the current code ends up with the right values, but
    on big-endian it blows. In r8169.c the same bug
    had been fixed in commit d35da12a40426184b1d0844104b1d464753eba19
    (r8169: endianness fixes).

    Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • maintainer change for s390 networking

    Signed-off-by: Ursula Braun
    Signed-off-by: Jeff Garzik

    Ursula Braun
     
  • Signed-off-by: Vitaly Bordug
    Signed-off-by: Jeff Garzik

    Vitaly Bordug
     
  • Signed-off-by: Vitaly Bordug
    Signed-off-by: Jeff Garzik

    Vitaly Bordug
     
  • Rename NET_SB1250_MAC to SB1250_MAC to follow the convention.

    Signed-off-by: Maciej W. Rozycki
    Signed-off-by: Jeff Garzik

    Maciej W. Rozycki
     
  • The SB1250 network interfaces are Gigabit Ethernet ones. Move the
    Kconfig entry to the appropriate section and add some help text.

    Signed-off-by: Maciej W. Rozycki
    Signed-off-by: Jeff Garzik

    Maciej W. Rozycki
     
  • Resubmitting the patch.

    This patch improves ethtool support for printing correct ring statistics,
    segmentation offload status, etc.

    Signed-off by: Dhananjay Phadke

    Signed-off-by: Jeff Garzik

    Dhananjay Phadke
     
  • Based on BenH's earlier work, this is a new version of the EMAC driver
    for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
    same ASIC is also found in the Axon bridge chip. This new version is
    designed to work in the arch/powerpc tree, using the device tree to
    probe the device, rather than the old and ugly arch/ppc OCP layer.

    This driver is designed to sit alongside the old driver (that lies in
    drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
    old driver is left in place to support arch/ppc until arch/ppc itself
    reaches its final demise (not too long now, with luck).

    This driver still has a number of things that could do with cleaning
    up, but I think they can be fixed up after merging. Specifically:
    - Should be adjusted to properly use the dma mapping API.
    Axon needs this.
    - Probe logic needs reworking, in conjuction with the general
    probing code for of_platform devices. The dependencies here between
    EMAC, MAL, ZMII etc. make this complicated. At present, it usually
    works, because we initialize and register the sub-drivers before the
    EMAC driver itself, and (being in driver code) runs after the devices
    themselves have been instantiated from the device tree.

    Signed-off-by: David Gibson
    Signed-off-by: Jeff Garzik

    David Gibson
     
  • Signed-off-by: Al Viro
    Signed-off-by: Jeff Garzik

    Al Viro
     
  • Since we are adding requirement for the PHYLIB for this driver, there should be a select for that

    Cc: Robin Getz
    Signed-off-by: Bryan Wu
    Signed-off-by: Jeff Garzik

    Bryan Wu