- 02 Sep, 2009 13 commits
-
-
Damian Lukowski authored
This patch updates the sysctl documentation concerning the interpretation of tcp_retries{1,2} and tcp_orphan_retries. Signed-off-by:Damian Lukowski <damian@tvk.rwth-aachen.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Damian Lukowski authored
This patch affects the retransmits_timed_out() function. Changes: 1) Variables have more meaningful names 2) retransmits_timed_out() has an introductionary comment. 3) Small coding style changes. Signed-off-by:
-
Mike McCormack authored
B0_CTST is a 24bit register according to the vendor driver (sk98lin). A 16bit read on B0_CTST will always return 0 for Y2_VAUX_AVAIL (1<<16), so use a 32bit read when testing Y2_VAUX_AVAIL Signed-off-by:
Mike McCormack <mikem@ring3k.org> Acked-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Mike McCormack authored
Refactor similar two sections of code that free buffers into one. Only call tx_init if all buffer allocations succeed. Signed-off-by:
-
Stephen Hemminger authored
Observed by Mike McCormack. The LED bit here is just a software controlled value used to turn on one of the LED's on some boards. The register value was wrong, which could have been causing some power control issues. Get rid of problematic define use the correct mask. Signed-off-by:
-
Michael S. Tsirkin authored
As tun always has an embeedded struct sock, use sk and sk_receive_queue fields instead of duplicating them in tun_struct. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Alexey Dobriyan authored
struct net::ipv6.ip6_dst_ops is separatedly dynamically allocated, but there is no fundamental reason for it. Embed it directly into struct netns_ipv6. For that: * move struct dst_ops into separate header to fix circular dependencies I honestly tried not to, it's pretty impossible to do other way * drop dynamical allocation, allocate together with netns For a change, remove struct dst_ops::dst_net, it's deducible by using container_of() given dst_ops pointer. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Eric Dumazet authored
We can speedup ether addresses compares using compare_ether_addr_64bits() instead of memcmp(). We make sure all operands are at least 8 bytes long and 16bits aligned (or better, long word aligned if possible) Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Reviewed-by:
Jiri Pirko <jpirko@redhat.com> Signed-off-by:
-
Eric Dumazet authored
To speedup ether addresses compares, we can use compare_ether_addr_64bits() (all operands are guaranteed to be at least 8 bytes long) Signed-off-by:
-
Mallikarjuna R Chilakala authored
ixgbe: Patch to fix 82599 multispeed fiber link issues when driver is loaded without any cable and reconnecting it to 1G partner In 82599 multi speed fiber case when driver is loaded without any cable and reconnecting the cable with a 1G partner does not bring up the link in 1Gb mode. When there is no link we first setup the link at 10G & 1G and then try to re-establish the link at highest speed 10G and thereby changing autoneg_advertised value to highest speed 10G. After connecting back the cable to a 1G link partner we never try 1G as autoneg advertised value is changed to link at 10G only. The following patch fixes the issue by properly initializing the autoneg_advertised value just before exiting from link setup routine. Signed-off-by:
Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com> Acked-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Peter P Waskiewicz Jr authored
When disabling the Rx and Tx data arbiters prior to configuration changes, the arbiters were not being shut down properly. This can create a race in the DCB hardware blocks, and potentially hang the arbiters. Also, the Tx descriptor arbiter shouldn't be disabled when applying configuration changes; disabling this arbiter can cause a Tx hang. Signed-off-by:
-
Mallikarjuna R Chilakala authored
Link code cleanup: a number of redundant functions and MAC variables are cleaned up, with some functions being consolidated into a single-purpose code path. Removed following deprecated link functions and mac variables * ixgbe_setup_copper_link_speed_82598 * ixgbe_setup_mac_link_speed_multispeed_fiber * ixgbe_setup_mac_link_speed_82599 * mac.autoneg, mac.autoneg_succeeded, phy.autoneg_wait_to_complete Signed-off-by:
-
Graham, David authored
Enabling VLAN filters (VFE) when the primary interface is brought up (per commit 78ed11a5) has caused problems for some users who manage their systems using IPMI over a VLAN. This is because when the driver enables the VLAN filter, this same filter table is enabled for the management channel, and the table is initially empty, which means that the IPMI/VLAN packets are filtered out and not received by the BMC. This is a problem only on e1000 class adapters, as it is only on e1000 that the filter table is common to the management and host streams. With this change, filtering is only enabled when one or more host VLANs exist, and is disabled when the last host VLAN is removed. VLAN filtering is always disabled when the primary interface is in promiscuous mode, and will be (re)enabled if VLANs exist when the interface exits promiscuous mode. Note that this does not completely resolve the issue for those using VLAN management, because if the host adds a VLAN, then the above problem occurs when that VLAN is enabled. However, it does mean the there is no problem for configurations where management is on a VLAN and the host is not. A complete solution to this issue would require further driver changes. The driver would need to discover if (and which) management VLANs are active before enabling VLAN filtering, so that it could ensure that the managed VLANs are included in the VLAN filter table. This discovery requires that the BMC identifies its VLAN in registers accessible to the driver, and at least on Dell PE2850 systems the BMC does not identify its VLAN to allow such discovery. Intel is pursuing this issue with the BMC vendor. Signed-off-by:
Dave Graham <david.graham@intel.com> Signed-off-by:
Krzysztof Piotr Oledzki <ole@ans.pl> Signed-off-by:
-
- 01 Sep, 2009 27 commits
-
-
Damian Lukowski authored
RFC 1122 specifies two threshold values R1 and R2 for connection timeouts, which may represent a number of allowed retransmissions or a timeout value. Currently linux uses sysctl_tcp_retries{1,2} to specify the thresholds in number of allowed retransmissions. For any desired threshold R2 (by means of time) one can specify tcp_retries2 (by means of number of retransmissions) such that TCP will not time out earlier than R2. This is the case, because the RTO schedule follows a fixed pattern, namely exponential backoff. However, the RTO behaviour is not predictable any more if RTO backoffs can be reverted, as it is the case in the draft "Make TCP more Robust to Long Connectivity Disruptions" (http://tools.ietf.org/html/draft-zimmermann-tcp-lcd). In the worst case TCP would time out a connection after 3.2 seconds, if the initial RTO equaled MIN_RTO and each backoff has been reverted. This patch introduces a function retransmits_timed_out(N), which calculates the timeout of a TCP connection, assuming an initial RTO of MIN_RTO and N unsuccessful, exponentially backed-off retransmissions. Whenever timeout decisions are made by comparing the retransmission counter to some value N, this function can be used, instead. The meaning of tcp_retries2 will be changed, as many more RTO retransmissions can occur than the value indicates. However, it yields a timeout which is similar to the one of an unpatched, exponentially backing off TCP in the same scenario. As no application could rely on an RTO greater than MIN_RTO, there should be no risk of a regression. Signed-off-by:Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Damian Lukowski authored
Here, an ICMP host/network unreachable message, whose payload fits to TCP's SND.UNA, is taken as an indication that the RTO retransmission has not been lost due to congestion, but because of a route failure somewhere along the path. With true congestion, a router won't trigger such a message and the patched TCP will operate as standard TCP. This patch reverts one RTO backoff, if an ICMP host/network unreachable message, whose payload fits to TCP's SND.UNA, arrives. Based on the new RTO, the retransmission timer is reset to reflect the remaining time, or - if the revert clocked out the timer - a retransmission is sent out immediately. Backoffs are only reverted, if TCP is in RTO loss recovery, i.e. if there have been retransmissions and reversible backoffs, already. Changes from v2: 1) Renaming of skb in tcp_v4_err() moved to another patch. 2) Reintroduced tcp_bound_rto() and __tcp_set_rto(). 3) Fixed code comments. Signed-off-by:
-
Damian Lukowski authored
This supplementary patch renames skb to icmp_skb in tcp_v4_err() in order to disambiguate from another sk_buff variable, which will be introduced in a separate patch. Signed-off-by:
-
Yi Zou authored
Add support for dcbnl_rtnl_ops.setapp/getapp to set or get the current user priority bitmap for the given application protocol. Currently, 82599 only supports setapp/getapp for Fiber Channel over Ethernet (FCoE) protocol. Signed-off-by:
Yi Zou <yi.zou@intel.com> Acked-by:
-
Yi Zou authored
Implements the dcbnl netlink setapp/getapp pair. When a setapp/getapp is received, dcbnl would just pass on to dcbnl_rtnl_op.setapp/getapp that are supposed to be implemented by the low level drivers. Signed-off-by:
-
Yi Zou authored
Add defines for dcbnl netlink attributes to support netlink message passing of setapp/getapp in dcbnl. Signed-off-by:
-
Yi Zou authored
Adds support of dcbnl setapp/getapp to dcbnl_rtnl_ops in netdev to allow LLDs to implement their corresponding dcbnl setapp/getapp ops to support the IEEE 802.1Q DCBX setapp/getapp commands. Signed-off-by:
-
Yi Zou authored
This patch adds dcbnl command definitions to support setapp/getapp functionality from the IEEE 802.1Qaz Data Center Bridging Capability Exchange protocol (DCBX) specification. Section 3.3 defines the application protocol and its 802.1p user priority in DCBX, which is implemented here as a pair of setapp/getapp commands in the kernel dcbnl for setting and retrieving the user priority for an given application protocol. The protocol is identified by the combination of an id and an idtype. Currently, when idtype is 0, the corresponding id gives the ether type of this protocol, e.g., for FCoE, it will be 0x8906; when idtype is 1, then the corresponding id gives the TCP or UDP port number. For more information regarding DCBX spec., please refer to the following: http://www.ieee802.org/1/files/public/docs2008/ az-wadekar-dcbx-capability-exchange-discovery-protocol-1108-v1.01.pdf Signed-off-by:
-
Yi Zou authored
This adds support to the net_device_ops.ndo_fcoe_enable/disable for 82599. This consequently allows us to dynamically turn FCoE offload feature on or off upon incoming calls to ndo_fcoe_enable/disable. When this happens, FCoE offload features are enabled/disabled accordingly, and this is regardless of whether DCB being turned on or not. Signed-off-by:
-
Yi Zou authored
This adds implementation of the net_devices_ops.ndo_fcoe_enable/_disable to the VLAN driver. It checks if the real_dev has support for ndo_fcoe_enable/ ndo_fcoe_disable and if so, passes on to call the associated real_dev. Signed-off-by:
-
Yi Zou authored
Add ndo_fcoe_enable/_disable to net_device_ops so the corresponding HW can initialize itself for FCoE traffic or clean up after FCoE traffic is done. This is expected to be called by the kernel FCoE stack upon receiving a request for creating an FCoE instance on the corresponding netdev interface. When implemented by the actual HW, the HW driver check the op code to perform corresponding initialization or clean up for FCoE. The initialization normally includes allocating extra queues for FCoE, setting corresponding HW registers for FCoE, indicating FCoE offload features via netdev, etc. The clean-up would include releasing the resources allocated for FCoE. Signed-off-by:
-
Stephen Hemminger authored
In a couple of cases collapse some extra code like: int retval = NETDEV_TX_OK; ... return retval; into return NETDEV_TX_OK; Signed-off-by:
-
Stephen Hemminger authored
Mostly just simple conversions: * ray_cs had bogus return of NET_TX_LOCKED but driver was not using NETIF_F_LLTX * hostap and ipw2x00 had some code that returned value from a called function that also had to change to return netdev_tx_t Signed-off-by: -
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Get rid of some bogus return wrapping as well. Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
These are all drivers that don't touch real hardware. Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Update all the pcmcia network drivers for netdev_tx_t. Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
