* Re: [PATCH v2] smsc95xx: mark link down on startup and let PHY interrupt deal with carrier changes
From: Stephane Fillod @ 2012-04-23 19:43 UTC (permalink / raw)
To: Paolo Pisati; +Cc: Steve Glendinning, netdev
In-Reply-To: <1335189920-31062-1-git-send-email-paolo.pisati@canonical.com>
lun, Apr 23, 2012, Paolo Pisati skribis:
> Without this patch sysfs reports the cable as present
>
> flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier
> 1
>
> while it's not:
>
> flag@flag-desktop:~$ sudo mii-tool eth0
> eth0: no link
>
> Tested on my Beagle XM.
>
> v2: added mantainer to the list of recipient
His e-mail address has changed, but somehow it has not been updated yet
in MAINTAINERS directory: steve.glendinning () shawell.net
> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
> ---
> drivers/net/usb/smsc95xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index 3444514..93d3252 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -1192,7 +1192,7 @@ static const struct driver_info smsc95xx_info = {
> .rx_fixup = smsc95xx_rx_fixup,
> .tx_fixup = smsc95xx_tx_fixup,
> .status = smsc95xx_status,
> - .flags = FLAG_ETHER | FLAG_SEND_ZLP,
> + .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_LINK_INTR,
> };
>
> static const struct usb_device_id products[] = {
Tested this fix successfuly on elder brother smsc75xx, on top of
another patch yet-to-submit to fix smsc75xx's MDIO access.
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: David Miller @ 2012-04-23 20:01 UTC (permalink / raw)
To: eric.dumazet
Cc: rick.jones2, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <1335201795.5205.35.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 23 Apr 2012 19:23:15 +0200
> On Mon, 2012-04-23 at 10:14 -0700, Rick Jones wrote:
>
>>
>> This will increase what can be queued for arriving segments in general
>> and not for ACKs specifically yes? (A possible issue that would have
>> come-up with my previous wondering about just increasing SO_RCVBUF as
>> SO_SNDBUF was increasing). Perhaps only add sk->sk_sndbuf to the limit
>> if the arriving segment contains no data?
>
> Thats the backlog limit that we tweak here.
>
> Its not a big deal if we allow a bit more packets to come and later drop
> them if we hit the real rcvbuf limit. (ACKS wont consume space, since
> they are freed as soon as processed)
Hmmm... why don't we just acknowledge reality and special case ACKs?
If a TCP packet is dataless we should just let it go through no matter
what and with no limits. It is by definition transient and will not
get queued up into the socket past this backlog stage.
This proposed patch allows non-dataless packets to eat more space in
the backlog, thus the concern and slight pushback. And from another
perspective, having the stack process data packets which will just
get dropped when we try to attach it to the receive queue is just
wasted work.
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Jesse Gross @ 2012-04-23 20:08 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev-yBygre7rU0TnMu66kgdUjQ, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA, David Miller
In-Reply-To: <20120423121934.195e898c-We1ePj4FEcvRI77zikRAJc56i+j3xesD0e7PPNI6Mm0@public.gmane.org>
On Mon, Apr 23, 2012 at 12:19 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Mon, 23 Apr 2012 15:15:33 -0400 (EDT)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Simon Horman <horms@verge.net.au>
>> Date: Mon, 23 Apr 2012 17:30:08 +0900
>>
>> > I'm pretty sure the patch I posted added encap_rcv to tcp_sock.
>> > Am I missing the point?
>>
>> It did, my eyes are failing me :-)
>>
>> > Currently I am setting up a listening socket. The Open vSwtich tunneling
>> > code transmits skbs and using either dev_queue_xmit() or ip_local_out().
>> > I'm not sure that I have exercised the ip_local_out() case yet.
>>
>> I don't see where on transmit you're going to realize the primary
>> stated benefit of STT, that being TSO/GSO.
>>
>> You'll probably want to gather as many packets as possible into a
>> larger STT frame for this purpose. And when switching between STT
>> tunnels, leave the packet alone since a GRO STT frame on receive will
>> transparently become a STT GSO frame on transmit.
>>
>
> I think the point of the TSO hack is to get around the MTU problem when tunneling.
> The added header of the tunnel eats into the the possible MTU. The use of TSO
> in STT is designed to deal with the fact that hardware can't do IP fragmentation
> of IP (or UDP).
That is a beneficial side effect, although the main goal is to just to
get back all of the offloads that are lost because hardware can't see
inside of encapsulated packets, with TSO, LRO, and RSS being the main
examples.
Assuming that the TCP stack generates large TSO frames on transmit
(which could be the local stack; something sent by a VM; or packets
received, coalesced by GRO and then encapsulated by STT) then you can
just prepend the STT header (possibly slightly adjusting things like
requested MSS, number of segments, etc. slightly). After that it's
possible to just output the resulting frame through the IP stack like
all tunnels do today. Similarly, on the other side the NIC will be
able to perform its normal offloading operations as well.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: David Miller @ 2012-04-23 20:13 UTC (permalink / raw)
To: jesse-l0M0P4e3n4LQT0dZR+AlfA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA
In-Reply-To: <CAEP_g=_3om5aR=P0ffa9421KhvYYrMEeE33TNcCC9UV6+XVWAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Date: Mon, 23 Apr 2012 13:08:49 -0700
> Assuming that the TCP stack generates large TSO frames on transmit
> (which could be the local stack; something sent by a VM; or packets
> received, coalesced by GRO and then encapsulated by STT) then you can
> just prepend the STT header (possibly slightly adjusting things like
> requested MSS, number of segments, etc. slightly). After that it's
> possible to just output the resulting frame through the IP stack like
> all tunnels do today.
Which seems to potentially suggest a stronger intergration of the STT
tunnel transmit path into our IP stack rather than the approach Simon
is taking
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Eric Dumazet @ 2012-04-23 20:37 UTC (permalink / raw)
To: David Miller
Cc: rick.jones2, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <20120423.160149.1515408777176168288.davem@davemloft.net>
On Mon, 2012-04-23 at 16:01 -0400, David Miller wrote:
> Hmmm... why don't we just acknowledge reality and special case ACKs?
>
Yes why not.
> If a TCP packet is dataless we should just let it go through no matter
> what and with no limits. It is by definition transient and will not
> get queued up into the socket past this backlog stage.
>
Even being transient we need a limit. Without copybreak, an ACK can cost
2048+256 bytes.
In my 10Gbit tests (standard netperf using 16K buffers), I've seen
backlogs of 300 ACK packets...
> This proposed patch allows non-dataless packets to eat more space in
> the backlog, thus the concern and slight pushback. And from another
> perspective, having the stack process data packets which will just
> get dropped when we try to attach it to the receive queue is just
> wasted work.
We could try to coalesce ACKs before backlogging them. I'll work on
this.
Thanks
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Jesse Gross @ 2012-04-23 20:53 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA
In-Reply-To: <20120423.161313.1582195533832554777.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem@davemloft.net> wrote:
> From: Jesse Gross <jesse@nicira.com>
> Date: Mon, 23 Apr 2012 13:08:49 -0700
>
>> Assuming that the TCP stack generates large TSO frames on transmit
>> (which could be the local stack; something sent by a VM; or packets
>> received, coalesced by GRO and then encapsulated by STT) then you can
>> just prepend the STT header (possibly slightly adjusting things like
>> requested MSS, number of segments, etc. slightly). After that it's
>> possible to just output the resulting frame through the IP stack like
>> all tunnels do today.
>
> Which seems to potentially suggest a stronger intergration of the STT
> tunnel transmit path into our IP stack rather than the approach Simon
> is taking
Did you have something in mind? Since the originating stack already
generates TSO frames today, it's just a few lines of code to adjust
for the addition of the STT header as the skb is encapsulated.
Otherwise, the transmit path is the same as something like GRE. L2TP
follows a fairly similar path - on receive it binds to a listening UDP
socket and on transmit it prepends a header, setups up checksum
offloading, and outputs directly via ip_queue_xmit().
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Rick Jones @ 2012-04-23 20:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <1335213446.5205.65.camel@edumazet-glaptop>
On 04/23/2012 01:37 PM, Eric Dumazet wrote:
> In my 10Gbit tests (standard netperf using 16K buffers), I've seen
> backlogs of 300 ACK packets...
Probably better to call that something other than 16K buffers - the send
size was probably 16K, which reflected SO_SNDBUF at the time the data
socket was created, but clearly SO_SNDBUF grew in that timeframe.
And those values are "standard" for netperf only in the context of
(default) Linux - on other platforms the defaults in the stack and so in
netperf are probably different.
The classic/migrated classic tests report only the initial socket buffer
sizes, not what they become by the end of the test:
raj@tardy:~/netperf2_trunk/src$ ./netperf -H 192.168.1.3
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.3 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 941.06
To see what they are at the end of the test requires more direct use of
the omni path. Either by way of test type:
raj@tardy:~/netperf2_trunk/src$ ./netperf -H 192.168.1.3 -t omni
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.3 ()
port 0 AF_INET
Local Remote Local Elapsed Throughput Throughput
Send Socket Recv Socket Send Time Units
Size Size Size (sec)
Final Final
266640 87380 16384 10.00 940.92 10^6bits/s
or omni output selection:
raj@tardy:~/netperf2_trunk/src$ ./netperf -H 192.168.1.3 -- -k
lss_size_req,lss_size,lss_size_end,rsr_size_req,rsr_size,rsr_size_end
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.3 () port 0 AF_INET
LSS_SIZE_REQ=-1
LSS_SIZE=16384
LSS_SIZE_END=266640
RSR_SIZE_REQ=-1
RSR_SIZE=87380
RSR_SIZE_END=87380
BTW, does it make sense that the SO_SNDBUF size on the netperf side
(lss_size_end - 2.6.38-14-generic kernel) grew larger than the SO_RCVBUF
on the netserver side? (3.2.0-rc4+)
rick jones
PS - here is data flowing the other way:
raj@tardy:~/netperf2_trunk/src$ ./netperf -H 192.168.1.3 -t TCP_MAERTS
-- -k lsr_size_req,lsr_size,lsr_size_end,rss_size_req,rss_size,rss_size_end
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.3 () port 0 AF_INET
LSR_SIZE_REQ=-1
LSR_SIZE=87380
LSR_SIZE_END=4194304
RSS_SIZE_REQ=-1
RSS_SIZE=16384
RSS_SIZE_END=65536
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: David Miller @ 2012-04-23 21:01 UTC (permalink / raw)
To: eric.dumazet
Cc: rick.jones2, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <1335213446.5205.65.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 23 Apr 2012 22:37:26 +0200
> We could try to coalesce ACKs before backlogging them. I'll work on
> this.
Great idea, although I wonder about the effect this could have on RTT
measurements. Instead of having N RTT measurements, we'd have just
one.
Granted, what happens right now wrt. RTT measurements with such huge
ACK backlogs isn't all that nice either.
Ideally, perhaps, we'd do a timestamp diff at the time we insert the
packet into the backlog. That way we wouldn't gain the RTT inaccuracy
introduced by such queueing delays and ACK backlogs.
Another way to look at it is that the coalesced scheme would actually
improve RTT measurements, since the most accurate (and least
"delayed") of the timestamps would be the only one processed :-)
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: David Miller @ 2012-04-23 21:08 UTC (permalink / raw)
To: jesse-l0M0P4e3n4LQT0dZR+AlfA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA
In-Reply-To: <CAEP_g=8EVOVgDaWnu3sd+qHxNZ7+ogjzBkuWvfVHNAqX2DRf=g@mail.gmail.com>
From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Date: Mon, 23 Apr 2012 13:53:42 -0700
> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>> From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
>> Date: Mon, 23 Apr 2012 13:08:49 -0700
>>
>>> Assuming that the TCP stack generates large TSO frames on transmit
>>> (which could be the local stack; something sent by a VM; or packets
>>> received, coalesced by GRO and then encapsulated by STT) then you can
>>> just prepend the STT header (possibly slightly adjusting things like
>>> requested MSS, number of segments, etc. slightly). After that it's
>>> possible to just output the resulting frame through the IP stack like
>>> all tunnels do today.
>>
>> Which seems to potentially suggest a stronger intergration of the STT
>> tunnel transmit path into our IP stack rather than the approach Simon
>> is taking
>
> Did you have something in mind?
A normal bonafide tunnel netdevice driver like GRE instead of the
openvswitch approach Simon is using.
^ permalink raw reply
* Re: [PATCH net-next] be2net: fix ethtool get settings
From: David Miller @ 2012-04-23 21:24 UTC (permalink / raw)
To: ajit.khaparde, ajitkhaparde; +Cc: netdev
In-Reply-To: <20120422045322.GA31559@akhaparde-VBox>
From: Ajit Khaparde <ajitkhaparde@gmail.com>
Date: Sat, 21 Apr 2012 23:53:22 -0500
> ethtool get settings was not displaying all the settings correctly.
> use the get_phy_info to get more information about the PHY to fix this.
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/3] Add capability to retrieve plug-in module EEPROM
From: David Miller @ 2012-04-23 21:28 UTC (permalink / raw)
To: smhodgson
Cc: netdev, bhutchings, bruce.w.allan, decot, alexander.h.duyck,
linux-kernel
In-Reply-To: <4F9031BF.10106@solarflare.com>
You can't just submit three seperate patches each with the same exact
Subject line.
Otherwise someone scanning the commit headers can't figure out what
is different in each of these changes.
There also is no signoff from Ben for patches #2 or #3, did he review
them? If so, why didn't he ACK or sign off on it? If not, why not?
^ permalink raw reply
* [PATCH RFC 0/2] e1000e: 82574 also needs ASPM L1 completely disabled
From: Chris Boot @ 2012-04-23 21:29 UTC (permalink / raw)
To: e1000-devel, netdev; +Cc: linux-kernel, nix, carolyn.wyborny, Chris Boot
In-Reply-To: <9BBC4E0CF881AA4299206E2E1412B6260E512E0C@ORSMSX102.amr.corp.intel.com>
After much toing and froing on LKML, netdev and the e1000 mailing lists
over the past few months we've determined that the 82574L needs to have
both ASPM L0s and L1 disabled or else it's likely to lock up. This
little series does just that, also cleaning up some now-unnecessary code
that disables L1 on the 82573 and 82574 if the MTU is greater than 1500
bytes.
Please note I haven't as-yet tested this code at all, but I do know that
disabling ASPM L1 on these NICs (using setpci) fixes the hangs that I
have been seeing on my Supermicro servers with X9SCL-F boards. I hope to
get the chance to install an updated kernel on my two afftected servers
later this week.
Chris Boot (2):
e1000e: Disable ASPM L1 on 82574
e1000e: Remove special case for 82573/82574 ASPM L1 disablement
drivers/net/ethernet/intel/e1000e/82571.c | 3 ++-
drivers/net/ethernet/intel/e1000e/netdev.c | 8 --------
2 files changed, 2 insertions(+), 9 deletions(-)
--
1.7.10
^ permalink raw reply
* [PATCH 1/2] e1000e: Disable ASPM L1 on 82574
From: Chris Boot @ 2012-04-23 21:29 UTC (permalink / raw)
To: e1000-devel, netdev; +Cc: linux-kernel, nix, carolyn.wyborny, Chris Boot
In-Reply-To: <1335216578-21542-1-git-send-email-bootc@bootc.net>
ASPM on the 82574 causes trouble. Currently the driver disables L0s for
this NIC but only disables L1 if the MTU is >1500. This patch simply
causes L1 to be disabled regardless of the MTU setting.
Signed-off-by: Chris Boot <bootc@bootc.net>
Cc: "Wyborny, Carolyn" <carolyn.wyborny@intel.com>
Cc: Nix <nix@esperi.org.uk>
Link: https://lkml.org/lkml/2012/3/19/362
---
drivers/net/ethernet/intel/e1000e/82571.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/82571.c b/drivers/net/ethernet/intel/e1000e/82571.c
index b3fdc69..c6d95f2 100644
--- a/drivers/net/ethernet/intel/e1000e/82571.c
+++ b/drivers/net/ethernet/intel/e1000e/82571.c
@@ -2061,8 +2061,9 @@ const struct e1000_info e1000_82574_info = {
| FLAG_HAS_SMART_POWER_DOWN
| FLAG_HAS_AMT
| FLAG_HAS_CTRLEXT_ON_LOAD,
- .flags2 = FLAG2_CHECK_PHY_HANG
+ .flags2 = FLAG2_CHECK_PHY_HANG
| FLAG2_DISABLE_ASPM_L0S
+ | FLAG2_DISABLE_ASPM_L1
| FLAG2_NO_DISABLE_RX,
.pba = 32,
.max_hw_frame_size = DEFAULT_JUMBO,
--
1.7.10
^ permalink raw reply related
* [PATCH 2/2] e1000e: Remove special case for 82573/82574 ASPM L1 disablement
From: Chris Boot @ 2012-04-23 21:29 UTC (permalink / raw)
To: e1000-devel, netdev; +Cc: nix, Chris Boot, linux-kernel
In-Reply-To: <1335216578-21542-1-git-send-email-bootc@bootc.net>
For the 82573, ASPM L1 gets disabled wholesale so this special-case code
is not required. For the 82574 the previous patch does the same as for
the 82573, disabling L1 on the adapter. Thus, this code is no longer
required and can be removed.
Signed-off-by: Chris Boot <bootc@bootc.net>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 19ab215..ea96cfd 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5293,14 +5293,6 @@ static int e1000_change_mtu(struct net_device *netdev, int new_mtu)
return -EINVAL;
}
- /* 82573 Errata 17 */
- if (((adapter->hw.mac.type == e1000_82573) ||
- (adapter->hw.mac.type == e1000_82574)) &&
- (max_frame > ETH_FRAME_LEN + ETH_FCS_LEN)) {
- adapter->flags2 |= FLAG2_DISABLE_ASPM_L1;
- e1000e_disable_aspm(adapter->pdev, PCIE_LINK_STATE_L1);
- }
-
while (test_and_set_bit(__E1000_RESETTING, &adapter->state))
usleep_range(1000, 2000);
/* e1000e_down -> e1000e_reset dependent on max_frame_size & mtu */
--
1.7.10
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Eric Dumazet @ 2012-04-23 21:30 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <4F95C22D.3010908@hp.com>
On Mon, 2012-04-23 at 13:57 -0700, Rick Jones wrote:
> On 04/23/2012 01:37 PM, Eric Dumazet wrote:
> > In my 10Gbit tests (standard netperf using 16K buffers), I've seen
> > backlogs of 300 ACK packets...
>
> Probably better to call that something other than 16K buffers - the send
> size was probably 16K, which reflected SO_SNDBUF at the time the data
> socket was created, but clearly SO_SNDBUF grew in that timeframe.
>
Maybe I was not clear : Application does sendmsg() of 16KB buffers.
Yet, in the small time it takes to perform this operation, softirq can
queue up to 300 packets coming from the other side.
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Eric Dumazet @ 2012-04-23 21:38 UTC (permalink / raw)
To: David Miller
Cc: rick.jones2, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <20120423.170101.1369764871919045849.davem@davemloft.net>
On Mon, 2012-04-23 at 17:01 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 23 Apr 2012 22:37:26 +0200
>
> > We could try to coalesce ACKs before backlogging them. I'll work on
> > this.
>
> Great idea, although I wonder about the effect this could have on RTT
> measurements. Instead of having N RTT measurements, we'd have just
> one.
>
> Granted, what happens right now wrt. RTT measurements with such huge
> ACK backlogs isn't all that nice either.
>
> Ideally, perhaps, we'd do a timestamp diff at the time we insert the
> packet into the backlog. That way we wouldn't gain the RTT inaccuracy
> introduced by such queueing delays and ACK backlogs.
>
> Another way to look at it is that the coalesced scheme would actually
> improve RTT measurements, since the most accurate (and least
> "delayed") of the timestamps would be the only one processed :-)
The big part of the work is not doing the coalesce, but also counting
the number of ACKS that are going to be carried into TCP stack if we
want cwnd being updated correctly.
Basically I'll have to add a new skb field (in cb[]) to properly count
number of ACKS 'included' in a single packet.
About the RTT, some congestion modules need TCP_CONG_RTT_STAMP but time
is taken when backlog processing is done, that is after backlog in/out
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Jesse Gross @ 2012-04-23 21:38 UTC (permalink / raw)
To: David Miller
Cc: shemminger, horms, jhs, stephen.hemminger, netdev, dev,
eric.dumazet
In-Reply-To: <20120423.170817.1103719420692884446.davem@davemloft.net>
On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem@davemloft.net> wrote:
> From: Jesse Gross <jesse@nicira.com>
> Date: Mon, 23 Apr 2012 13:53:42 -0700
>
>> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Jesse Gross <jesse@nicira.com>
>>> Date: Mon, 23 Apr 2012 13:08:49 -0700
>>>
>>>> Assuming that the TCP stack generates large TSO frames on transmit
>>>> (which could be the local stack; something sent by a VM; or packets
>>>> received, coalesced by GRO and then encapsulated by STT) then you can
>>>> just prepend the STT header (possibly slightly adjusting things like
>>>> requested MSS, number of segments, etc. slightly). After that it's
>>>> possible to just output the resulting frame through the IP stack like
>>>> all tunnels do today.
>>>
>>> Which seems to potentially suggest a stronger intergration of the STT
>>> tunnel transmit path into our IP stack rather than the approach Simon
>>> is taking
>>
>> Did you have something in mind?
>
> A normal bonafide tunnel netdevice driver like GRE instead of the
> openvswitch approach Simon is using.
Ahh, yes, that I agree with. Independent of this, there's work being
done to make it so that OVS can use the normal in-tree tunneling code
and not need its own. Once that's done I expect that STT will follow
the same model.
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Rick Jones @ 2012-04-23 21:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <1335216631.5205.71.camel@edumazet-glaptop>
On 04/23/2012 02:30 PM, Eric Dumazet wrote:
> On Mon, 2012-04-23 at 13:57 -0700, Rick Jones wrote:
>> Probably better to call that something other than 16K buffers - the send
>> size was probably 16K, which reflected SO_SNDBUF at the time the data
>> socket was created, but clearly SO_SNDBUF grew in that timeframe.
>>
>
>
> Maybe I was not clear : Application does sendmsg() of 16KB buffers.
I'd probably call that a 16K send test. The root of the issue being
there being "send buffers" and "send socket buffers" (and their receive
versions).
My "canonical" test - at least one that appears in most of my
contemporary scripts uses a 64K send size for the bulk transfer tests.
I switch back-and-forth between tests which allow the socket buffer size
to be determined automagically, and those where I set both sides' socket
buffers to 1M via the test-specific -s and -S options. In "netperf
speak" those would probably be "x64K" and "1Mx64k" respectively. More
generally "<socket buffer size>x<send size>" (I rarely set/specify the
receive size in those tests, leaving it at whatever SO_RCVBUF is at the
start.
> Yet, in the small time it takes to perform this operation, softirq can
> queue up to 300 packets coming from the other side.
There is more to it than just queue-up 16 KB right?
rick
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Rick Jones @ 2012-04-23 21:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <4F95CECF.6030901@hp.com>
On 04/23/2012 02:51 PM, Rick Jones wrote:
> On 04/23/2012 02:30 PM, Eric Dumazet wrote:
>> On Mon, 2012-04-23 at 13:57 -0700, Rick Jones wrote:
>>> Probably better to call that something other than 16K buffers - the send
>>> size was probably 16K, which reflected SO_SNDBUF at the time the data
>>> socket was created, but clearly SO_SNDBUF grew in that timeframe.
>>>
>>
>>
>> Maybe I was not clear : Application does sendmsg() of 16KB buffers.
>
> I'd probably call that a 16K send test. The root of the issue being
> there being "send buffers" and "send socket buffers" (and their receive
> versions).
>
> My "canonical" test - at least one that appears in most of my
> contemporary scripts uses a 64K send size for the bulk transfer tests. I
> switch back-and-forth between tests which allow the socket buffer size
> to be determined automagically, and those where I set both sides' socket
> buffers to 1M via the test-specific -s and -S options. In "netperf
> speak" those would probably be "x64K" and "1Mx64k" respectively. More
> generally "<socket buffer size>x<send size>" (I rarely set/specify the
> receive size in those tests, leaving it at whatever SO_RCVBUF is at the
> start.
>
>> Yet, in the small time it takes to perform this operation, softirq can
>> queue up to 300 packets coming from the other side.
>
> There is more to it than just queue-up 16 KB right?
I should have added that 300 ACKs seems huge as a backlog. At
ack-every-other that is 300 * 1448 * 2 or 868800 bytes worth of ACKs.
That sounds like a great deal more than just one 16KB send's worth of
being held-off. I mean at 10Gbe speeds (using your 54 usec for 64KB)
that represents data which took something like three quarters of a
millisecond to transmit on the wire.
rick
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Eric Dumazet @ 2012-04-23 22:05 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <4F95CECF.6030901@hp.com>
On Mon, 2012-04-23 at 14:51 -0700, Rick Jones wrote:
> On 04/23/2012 02:30 PM, Eric Dumazet wrote:
> > Yet, in the small time it takes to perform this operation, softirq can
> > queue up to 300 packets coming from the other side.
>
> There is more to it than just queue-up 16 KB right?
At full rate, we send 825.000 packets per second, and should receive
412.000 ACKS per second if receiver is standard TCP.
The ACK are not smooth, because receiver also have a huge backlog issue
and can send train of ACKS. (I have seen backlogs on receiver using more
than 500 us to be processed)
If the copyin(16KB) from user to kernel takes some us (preempt,
irqs...), its pretty easy to catch an ACK train in this window.
^ permalink raw reply
* [PATCH net] net/davinci_emac: fix failing PHY connect attempts
From: Anatolij Gustschin @ 2012-04-23 22:06 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller
PHY connect attempts fail if no PHY id is specified in the emac platform
data and another mdio bus has been registered before 'davinci_mdio' bus. In
this case when configuring the interface, there will be an attempt to
connect to already attached PHY on the previously registered mdio bus:
net eth1: PHY already attached
net eth1: could not connect to phy smsc911x-0:01
IP-Config: Failed to open eth1
IP-Config: Device `eth1' not found
Fix this by modifying match_first_device() to match first PHY device
on 'davinci_mdio' bus.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
drivers/net/ethernet/ti/davinci_emac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 174a334..08aff1a 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1511,7 +1511,7 @@ static int emac_devioctl(struct net_device *ndev, struct ifreq *ifrq, int cmd)
static int match_first_device(struct device *dev, void *data)
{
- return 1;
+ return !strncmp(dev_name(dev), "davinci_mdio", 12);
}
/**
--
1.7.1
^ permalink raw reply related
* [PATCH] net sysctl: Add place holder functions for when sysctl support is compiled out of the kernel.
From: Eric W. Biederman @ 2012-04-23 22:13 UTC (permalink / raw)
To: David Miller; +Cc: Stephen Rothwell, linux-next, LKML, netdev, Randy Dunlap
In-Reply-To: <4F958598.6080305@xenotime.net>
Randy Dunlap <rdunlap@xenotime.net> reported:
> On 04/23/2012 12:07 AM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20120420:
>
>
>
> ERROR: "unregister_net_sysctl_table" [net/phonet/phonet.ko] undefined!
> ERROR: "register_net_sysctl" [net/phonet/phonet.ko] undefined!
>
> when CONFIG_SYSCTL is not enabled.
Add static inline stub functions to gracefully handle the case when sysctl
support is not present.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
include/net/net_namespace.h | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 3ee4a3d..ac9195e 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -284,11 +284,20 @@ struct ctl_table_header;
#ifdef CONFIG_SYSCTL
extern int net_sysctl_init(void);
-#else
-static inline int net_sysctl_init(void) { return 0; }
-#endif
extern struct ctl_table_header *register_net_sysctl(struct net *net,
const char *path, struct ctl_table *table);
extern void unregister_net_sysctl_table(struct ctl_table_header *header);
+#else
+static inline int net_sysctl_init(void) { return 0; }
+static inline struct ctl_table_header *register_net_sysctl(struct net *net,
+ const char *path, struct ctl_table *table)
+{
+ return NULL;
+}
+static inline void unregister_net_sysctl_table(struct ctl_table_header *header)
+{
+}
+#endif
+
#endif /* __NET_NET_NAMESPACE_H */
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Rick Jones @ 2012-04-23 22:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, therbert, ncardwell, maze, ycheng,
ilpo.jarvinen
In-Reply-To: <1335218707.5205.87.camel@edumazet-glaptop>
On 04/23/2012 03:05 PM, Eric Dumazet wrote:
> On Mon, 2012-04-23 at 14:51 -0700, Rick Jones wrote:
>> On 04/23/2012 02:30 PM, Eric Dumazet wrote:
>
>>> Yet, in the small time it takes to perform this operation, softirq can
>>> queue up to 300 packets coming from the other side.
>>
>> There is more to it than just queue-up 16 KB right?
>
> At full rate, we send 825.000 packets per second, and should receive
> 412.000 ACKS per second if receiver is standard TCP.
>
> The ACK are not smooth, because receiver also have a huge backlog issue
> and can send train of ACKS. (I have seen backlogs on receiver using more
> than 500 us to be processed)
>
> If the copyin(16KB) from user to kernel takes some us (preempt,
> irqs...), its pretty easy to catch an ACK train in this window.
Is it at all possible to have the copies happen without the connection
being locked? If indeed it is possible to be held-off with the
connection locked for the better part of 3/4 of a millisecond, just what
will that do to 40 or 100 GbE? If you've been seeing queues of 300 ACKs
at 10 GbE that would be 3000 at 100 GbE, and assuming those are all in a
2048 byte buffer thats 6MB just of ACKs. I suppose 100GbE does mean
non-trivial quantities of buffering anyway but that does still seem
rather high.
rick
thank goodness for GRO's ACK stretching as an ACK avoidance heuristic I
guess...
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Simon Horman @ 2012-04-23 22:32 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
stephen.hemminger-ZtmgI6mnKB3QT0dZR+AlfA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA, David Miller
In-Reply-To: <CAEP_g=-52GOr3LzbUB+97ftNQBZV=7NWXqfWN6GMfq5KmdO25A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
> On Mon, Apr 23, 2012 at 2:08 PM, David Miller <davem@davemloft.net> wrote:
> > From: Jesse Gross <jesse@nicira.com>
> > Date: Mon, 23 Apr 2012 13:53:42 -0700
> >
> >> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <davem@davemloft.net> wrote:
> >>> From: Jesse Gross <jesse@nicira.com>
> >>> Date: Mon, 23 Apr 2012 13:08:49 -0700
> >>>
> >>>> Assuming that the TCP stack generates large TSO frames on transmit
> >>>> (which could be the local stack; something sent by a VM; or packets
> >>>> received, coalesced by GRO and then encapsulated by STT) then you can
> >>>> just prepend the STT header (possibly slightly adjusting things like
> >>>> requested MSS, number of segments, etc. slightly). After that it's
> >>>> possible to just output the resulting frame through the IP stack like
> >>>> all tunnels do today.
> >>>
> >>> Which seems to potentially suggest a stronger intergration of the STT
> >>> tunnel transmit path into our IP stack rather than the approach Simon
> >>> is taking
> >>
> >> Did you have something in mind?
> >
> > A normal bonafide tunnel netdevice driver like GRE instead of the
> > openvswitch approach Simon is using.
>
> Ahh, yes, that I agree with. Independent of this, there's work being
> done to make it so that OVS can use the normal in-tree tunneling code
> and not need its own. Once that's done I expect that STT will follow
> the same model.
Hi Jesse,
I am wondering how firm the plans to on allowing OVS to use in-tree tunnel
code are. I'm happy to move my efforts over to an in-tree STT implementation
but ultimately I would like to get STT running in conjunction with OVS.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH] net sysctl: Add place holder functions for when sysctl support is compiled out of the kernel.
From: Randy Dunlap @ 2012-04-23 22:38 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, Stephen Rothwell, linux-next, LKML, netdev
In-Reply-To: <m1lilmt7v5.fsf_-_@fess.ebiederm.org>
On 04/23/2012 03:13 PM, Eric W. Biederman wrote:
>
> Randy Dunlap <rdunlap@xenotime.net> reported:
>> On 04/23/2012 12:07 AM, Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20120420:
>>
>>
>>
>> ERROR: "unregister_net_sysctl_table" [net/phonet/phonet.ko] undefined!
>> ERROR: "register_net_sysctl" [net/phonet/phonet.ko] undefined!
>>
>> when CONFIG_SYSCTL is not enabled.
>
> Add static inline stub functions to gracefully handle the case when sysctl
> support is not present.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Yep, that works.
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Thanks.
> ---
> include/net/net_namespace.h | 15 ++++++++++++---
> 1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index 3ee4a3d..ac9195e 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -284,11 +284,20 @@ struct ctl_table_header;
>
> #ifdef CONFIG_SYSCTL
> extern int net_sysctl_init(void);
> -#else
> -static inline int net_sysctl_init(void) { return 0; }
> -#endif
> extern struct ctl_table_header *register_net_sysctl(struct net *net,
> const char *path, struct ctl_table *table);
> extern void unregister_net_sysctl_table(struct ctl_table_header *header);
> +#else
> +static inline int net_sysctl_init(void) { return 0; }
> +static inline struct ctl_table_header *register_net_sysctl(struct net *net,
> + const char *path, struct ctl_table *table)
> +{
> + return NULL;
> +}
> +static inline void unregister_net_sysctl_table(struct ctl_table_header *header)
> +{
> +}
> +#endif
> +
>
> #endif /* __NET_NET_NAMESPACE_H */
--
~Randy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox