- 02 Sep, 2009 10 commits
-
-
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: Mike McCormack <mikem@ring3k.org> Acked-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: 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: David S. Miller <davem@davemloft.net>
-
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: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 01 Sep, 2009 30 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: Damian Lukowski <damian@tvk.rwth-aachen.de> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <damian@tvk.rwth-aachen.de> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Damian Lukowski <damian@tvk.rwth-aachen.de> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <yi.zou@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: David S. Miller <davem@davemloft.net>
-
Yi Zou authored
Add defines for dcbnl netlink attributes to support netlink message passing of setapp/getapp in dcbnl. Signed-off-by: Yi Zou <yi.zou@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: David S. Miller <davem@davemloft.net>
-
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 <yi.zou@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: David S. Miller <davem@davemloft.net>
-
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 <yi.zou@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: David S. Miller <davem@davemloft.net>
-
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 <yi.zou@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: David S. Miller <davem@davemloft.net>
-
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 <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Get rid of some bogus return wrapping as well. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
These are all drivers that don't touch real hardware. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Update all the pcmcia network drivers for netdev_tx_t. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
The transmit function should only return one of three possible values, some drivers got confused and returned errno's or other values. This changes the definition so that this can be caught at compile time. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-