- 10 Oct, 2007 40 commits
-
-
Daniel Lezcano authored
Doing this makes loopback.c a better example of how to do a simple network device, and it removes the special case single static allocation of a struct net_device, hopefully making maintenance easier. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Daniel Lezcano <dlezcano@fr.ibm.com> Acked-By:
Kirill Korotaev <dev@sw.ru> Acked-by:
Benjamin Thery <benjamin.thery@bull.net>
-
Daniel Lezcano authored
This patch replaces all occurences to the static variable loopback_dev to a pointer loopback_dev. That provides the mindless, trivial, uninteressting change part for the dynamic allocation for the loopback. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Johannes Berg authored
Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
David S. Miller authored
Signed-off-by: -
Ilpo Järvinen authored
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 <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Ilpo Järvinen authored
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.htmlSigned-off-by:
-
Ilpo Järvinen authored
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 authored
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 authored
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 authored
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 authored
In addition, fix its function comment spacing. Signed-off-by: -
Ilpo Järvinen authored
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 authored
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:
-
Michael Buesch authored
The remaining warning in phy.c will be fixed later. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Jeff Garzik <jeff@garzik.org>
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Note: we still have several fishy areas - mcast filter and vlan handling. Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
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 authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
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 d35da12a (r8169: endianness fixes). Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Ursula Braun authored
maintainer change for s390 networking Signed-off-by:
Ursula Braun <braunu@de.ibm.com> Signed-off-by:
-
Vitaly Bordug authored
Signed-off-by:
Vitaly Bordug <vitb@kernel.crashing.org> Signed-off-by:
-
Vitaly Bordug authored
Signed-off-by:
-
Maciej W. Rozycki authored
Rename NET_SB1250_MAC to SB1250_MAC to follow the convention. Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
-
Maciej W. Rozycki authored
The SB1250 network interfaces are Gigabit Ethernet ones. Move the Kconfig entry to the appropriate section and add some help text. Signed-off-by:
-
Dhananjay Phadke authored
Resubmitting the patch. This patch improves ethtool support for printing correct ring statistics, segmentation offload status, etc. Signed-off by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: -
David Gibson authored
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 <david@gibson.dropbear.id.au> Signed-off-by:
-
