* Re: [PATCH v3] tcp: ioctl type SIOCOUTQNSD returns amount of data not sent
From: David Miller @ 2011-03-10 22:16 UTC (permalink / raw)
To: hagen
Cc: sledz, netdev, linux-kernel, alan, kuznet, pekkas, jmorris,
yoshfuji, kaber, m.schuknecht
In-Reply-To: <20110310221205.GF3121@nuttenaction>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Thu, 10 Mar 2011 23:12:05 +0100
> * David Miller | 2011-03-09 14:09:51 [-0800]:
>
>>From: Steffen Sledz <sledz@dresearch.de>
>>Date: Sun, 6 Mar 2011 20:59:55 +0100
>>
>>> From: Mario Schuknecht <m.schuknecht@dresearch.de>
>>>
>>> In contrast to SIOCOUTQ which returns the amount of data sent
>>> but not yet acknowledged plus data not yet sent this patch only
>>> returns the data not sent.
>>>
>>> For various methods of live streaming bitrate control it may
>>> be helpful to know how much data are in the tcp outqueue are
>>> not sent yet.
>>>
>>> Signed-off-by: Mario Schuknecht <m.schuknecht@dresearch.de>
>>> Signed-off-by: Steffen Sledz <sledz@dresearch.de>
>>
>>Applied, thanks.
>
> A little bit late - but why not using struct tcp_info for that? The
> information is already provided via getsockopt(TCP_INFO).
It's pretty heavy handed to copy that entire TCP_INFO struct into
userspace during every I/O sequence the application makes.
^ permalink raw reply
* [patch] ariadne: remove redundant NULL check
From: j223yang @ 2011-03-10 22:36 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel
Simply remove redundant 'dev' NULL check.
Source code uses spaces instead of TAB, except 'printk' and 'return' lines.
Signed-off-by: Jinqiu Yang <crindy646@gmail.com>
---
ariadne.c | 5 -----
1 file changed, 5 deletions(-)
--- a/drivers/net/ariadne.c 2011-03-10 11:20:14.076039323 -0500
+++ b/drivers/net/ariadne.c 2011-03-10 11:21:59.111164537 -0500
@@ -425,11 +425,6 @@ static irqreturn_t ariadne_interrupt(int
int csr0, boguscnt;
int handled = 0;
- if (dev == NULL) {
- printk(KERN_WARNING "ariadne_interrupt(): irq for unknown device.\n");
- return IRQ_NONE;
- }
-
lance->RAP = CSR0; /* PCnet-ISA Controller Status */
if (!(lance->RDP & INTR)) /* Check if any interrupt has been */
^ permalink raw reply
* Re: [patch] ariadne: remove redundant NULL check
From: David Miller @ 2011-03-10 22:39 UTC (permalink / raw)
To: j223yang; +Cc: netdev, linux-kernel
In-Reply-To: <20110310223636.GA11399@asset.uwaterloo.ca>
From: j223yang@asset.uwaterloo.ca
Date: Thu, 10 Mar 2011 17:36:37 -0500
> Simply remove redundant 'dev' NULL check.
> Source code uses spaces instead of TAB, except 'printk' and 'return' lines.
>
>
> Signed-off-by: Jinqiu Yang <crindy646@gmail.com>
Patch is still corrupted by your email client, the same way as before.
And when you fix it, you don't need to mention this in the commit
message.
Please, take the time to do some testing by sending the patch to
yourself, and then try to apply the patch in the email you receive.
^ permalink raw reply
* Re: [patch] ariadne: remove redundant NULL check
From: David Miller @ 2011-03-10 22:40 UTC (permalink / raw)
To: j223yang; +Cc: netdev, linux-kernel
In-Reply-To: <20110310.143942.183042624.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 10 Mar 2011 14:39:42 -0800 (PST)
> From: j223yang@asset.uwaterloo.ca
> Date: Thu, 10 Mar 2011 17:36:37 -0500
>
>> Simply remove redundant 'dev' NULL check.
>> Source code uses spaces instead of TAB, except 'printk' and 'return' lines.
>>
>>
>> Signed-off-by: Jinqiu Yang <crindy646@gmail.com>
>
> Patch is still corrupted by your email client, the same way as before.
Sorry, I apologize, this is not your fault.
This is one of those terrible old drivers that have bad coding
style.
I'll apply this patch, thank you.
^ permalink raw reply
* Re: [PATCH 3/8] macb: convert printk to pr_ and friends
From: Joe Perches @ 2011-03-10 22:48 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <1299751843-9743-4-git-send-email-jamie@jamieiles.com>
On Thu, 2011-03-10 at 10:10 +0000, Jamie Iles wrote:
> macb is already using the dev_dbg() and friends helpers so use pr_foo()
> along with a pr_fmt() definition to make the printing a little cleaner.
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Hi Jamie.
Because these conversions use a struct net_device,
they would be better as:
netdev_<foo>(struct net_device *dev, const char *fmt, ...)
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> @@ -175,11 +176,11 @@ static void macb_handle_link_change(struct net_device *dev)
>
> if (status_change) {
> if (phydev->link)
> - printk(KERN_INFO "%s: link up (%d/%s)\n",
> + pr_info("%s: link up (%d/%s)\n",
> dev->name, phydev->speed,
> DUPLEX_FULL == phydev->duplex ? "Full":"Half");
netdev_info(dev, "link up (%d/%s)\n",
phydev->speed,
phydev->duplex == DUPLEX_FULL ? "Full" : "Half");
> else
> - printk(KERN_INFO "%s: link down\n", dev->name);
> + pr_info("%s: link down\n", dev->name);
netdev_info(dev, "link down\n");
> @@ -193,7 +194,7 @@ static int macb_mii_probe(struct net_device *dev)
>
> phydev = phy_find_first(bp->mii_bus);
> if (!phydev) {
> - printk (KERN_ERR "%s: no PHY found\n", dev->name);
> + pr_err("%s: no PHY found\n", dev->name);
netdev_err(dev, "no PHY found\n");
> @@ -206,7 +207,7 @@ static int macb_mii_probe(struct net_device *dev)
> PHY_INTERFACE_MODE_RMII :
> PHY_INTERFACE_MODE_MII);
> if (ret) {
> - printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name);
> + pr_err("%s: Could not attach to PHY\n", dev->name);
netdev_err(dev, "could not attach to PHY\n");
etc...
^ permalink raw reply
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Stephen Hemminger @ 2011-03-10 23:28 UTC (permalink / raw)
To: Lucas Nussbaum; +Cc: netdev, Sangtae Ha
In-Reply-To: <20110308093215.GA23842@xanadu.blop.info>
On Tue, 8 Mar 2011 10:32:15 +0100
Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> CUBIC Hystart uses two heuristics to exit slow start earlier, before
> losses start to occur. Unfortunately, it tends to exit slow start far too
> early, causing poor performance since convergence to the optimal cwnd is
> then very slow. This was reported in
> http://permalink.gmane.org/gmane.linux.network/188169 and
> https://partner-bugzilla.redhat.com/show_bug.cgi?id=616985
Ignore the RHEL bug. RHEL 5 ships with TCP BIC (not CUBIC) by default.
There are many research papers which show that BIC is too aggressive,
and not fair.
--
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-03-10 23:34 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
I think all the major known regressions are cured and we should be
ready to go for 2.6.38-final
1) Fix regression in IPV6 route lookups, cures BZ 29252 and 30462
2) We use ifa_address where we mean ifa_local in ipv4 stack,
reported by Julian Anastasov.
3) pktgen time reporting units are wrong, fix from Daniel Turull
4) IPV6=m/BRIDGE=y results in broken build, fix from Randy Dunlap.
5) Network modloading security fix needs to handle ip6 tunnel case,
fix from Stephen Hemminger.
6) bnx2x driver fixes from Dmitry Kravkov and Eilon Greenstein.
7) smsc911x drops full sized VLAN packets erroneously, fix from Göran
Weinholt.
8) Fix Makefile logic for entering net/ipv6 directory for the case
where we are only building {exthdrs,addrconf}_core.o Fix from
Thomas Graf.
9) Multi-threaded signal handling is botched because we use plain
mutex_lock() to synchronize readers in recvmsg(), change to use
mutex_lock_interruptible(). Fix from Rainer Weikusat.
10) Bonding driver state machine locking doesn't cover enough code,
fix from Nils Carlson.
12) Fix BUG_ON trigger in RDS stack, fix from Neil Horman.
13) Multicase handling fixes to r6040 driver from Shawn Lin.
Please pull, thanks a lot!
The following changes since commit 9179746652faf0aba07b8b7f770dcf29892a24c6:
Merge branch 'media_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 (2011-03-10 13:22:10 -0800)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Daniel Turull (1):
pktgen: fix errata in show results
David S. Miller (3):
ipv4: Fix erroneous uses of ifa_address.
ipv6: Don't create clones of host routes.
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
Dmitry Kravkov (4):
bnx2x: fix non-pmf device load flow
bnx2x: fix link notification
bnx2x: (NPAR) prevent HW access in D3 state
bnx2x: fix MaxBW configuration
Florian Fainelli (1):
r6040: bump to version 0.27 and date 23Feb2011
Göran Weinholt (1):
net/smsc911x.c: Set the VLAN1 register to fix VLAN MTU problem
Jon Mason (1):
vxge: update MAINTAINERS
Neil Horman (1):
rds: prevent BUG_ON triggering on congestion map updates
Nicolas Kaiser (1):
drivers/net/macvtap: fix error check
Nils Carlson (2):
bonding 802.3ad: Fix the state machine locking v2
bonding 802.3ad: Rename rx_machine_lock to state_machine_lock
Rainer Weikusat (1):
net: fix multithreaded signal handling in unix recv routines
Randy Dunlap (1):
net: bridge builtin vs. ipv6 modular
Shawn Lin (1):
r6040: fix multicast operations
Thomas Graf (1):
net: Enter net/ipv6/ even if CONFIG_IPV6=n
j223yang@asset.uwaterloo.ca (1):
ariadne: remove redundant NULL check
stephen hemminger (1):
ip6ip6: autoload ip6 tunnel
MAINTAINERS | 5 +-
drivers/net/ariadne.c | 5 --
drivers/net/bnx2x/bnx2x.h | 5 +-
drivers/net/bnx2x/bnx2x_cmn.c | 22 +++++++
drivers/net/bnx2x/bnx2x_cmn.h | 9 +++
drivers/net/bnx2x/bnx2x_ethtool.c | 18 +++---
drivers/net/bnx2x/bnx2x_main.c | 19 +++---
drivers/net/bonding/bond_3ad.c | 32 ++++++----
drivers/net/bonding/bond_3ad.h | 3 +-
drivers/net/macvtap.c | 3 +-
drivers/net/r6040.c | 115 +++++++++++++++++++++----------------
drivers/net/smsc911x.c | 5 ++
net/Makefile | 4 +-
net/bridge/Kconfig | 1 +
net/core/pktgen.c | 2 +-
net/ipv4/devinet.c | 6 +-
net/ipv6/ip6_tunnel.c | 1 +
net/ipv6/route.c | 4 +-
net/rds/ib_send.c | 5 +-
net/rds/loop.c | 11 +++-
net/unix/af_unix.c | 17 ++++-
21 files changed, 182 insertions(+), 110 deletions(-)
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-10 23:49 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20110310.153444.115930379.davem@davemloft.net>
On Thu, Mar 10, 2011 at 3:34 PM, David Miller <davem@davemloft.net> wrote:
>
> David S. Miller (3):
> ipv4: Fix erroneous uses of ifa_address.
> ipv6: Don't create clones of host routes.
> Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
David, why do you keep on doing those broken back-merges?
It's the _one_ thing you keep on doing wrong, and I don't understand
it. Just the merge message you get should tell you that you're doing
something total SH*T.
Look at that commit message:
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
That is literally the WHOLE message. Ask yourself: is that commit
doing anything useful? Does the commit message explain what it is
doing, and why you are doing it?
And if not (and if you came to some other conclusion than "no" to
either of those questions, you should explain it), then why do you do
it? It sure doesn't help me: it just makes it harder for me to
see/follow the history (and if it's harder for me to see, then it's
harder for _others_ to see). There was no conflict (I double-checked),
and there was no explanation for why it would be done.
Now, I admit that it's a git usability bug: for normal "git commit",
git will _force_ you to write a message, and sadly, for merges, I made
it instead just do the message automatically. My bad. I designed it
for the kind of merges I do, where the the automatic merge message
actually tells you what the merge is all about. But for back-merges,
the automatic message is totally worthless, and it is DOUBLY worthless
when you do it the way you do it, namely from some local directory of
your own.
That's just STUPID. Look at that message once more, and ponder. What does
"Merge branch 'master' of /home/davem/src/GIT/linux-2.6/"
tell anybody? It's not even pointing to my repository, and you have
actively BROKEN the small amount of smarts (as admitted above, not
enough) that git does do normally, which is at least tell you where
the merge comes from. You broke it by fetching my repository into your
own anonymous tree, and then merging it from there, and thus the
automatic merge message lost sight of the fact that it was my upstream
tree, because you had made it your own random repo.
Grr. This has been going on for too long. Don't do it. Don't do random
backwards merges without explanations, and with the actual source data
removed.
We're _really_ good at doing commit messages, and the kernel commit
log should be a great example to other projects. But in the last week
or so, I've now _twice_ had to flame core developers for making
totally useless commit messages.
So don't do back-merges. And if you DO do back-merges, don't make the
commit message totally useless.
You can use either 'git commit --amend" to fix the message afterwards
and explain WHY you did the stupid thing, or you can just do "git pull
--no-commit" to not actually commit the merge and then write your
commit message as you do it. But preferably you shouldn't do the
back-merges at all.
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2011-03-10 23:55 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <AANLkTimnHtVS=SFopgyjAAQDW8bXDKDXf+YvEtPdpPsA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 10 Mar 2011 15:49:40 -0800
> Grr. This has been going on for too long. Don't do it. Don't do random
> backwards merges without explanations, and with the actual source data
> removed.
>
> We're _really_ good at doing commit messages, and the kernel commit
> log should be a great example to other projects. But in the last week
> or so, I've now _twice_ had to flame core developers for making
> totally useless commit messages.
>
> So don't do back-merges. And if you DO do back-merges, don't make the
> commit message totally useless.
>
> You can use either 'git commit --amend" to fix the message afterwards
> and explain WHY you did the stupid thing, or you can just do "git pull
> --no-commit" to not actually commit the merge and then write your
> commit message as you do it. But preferably you shouldn't do the
> back-merges at all.
I'm sorry about this, won't happen again.
I should have put:
Merge to get commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b
("net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules")
so that we can add Stephen Hemminger's fix to handle ip6 tunnels
as well, which uses the MODULE_ALIAS_NETDEV() macro created by
that change.
Again, sorry.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-11 0:01 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <AANLkTimnHtVS=SFopgyjAAQDW8bXDKDXf+YvEtPdpPsA@mail.gmail.com>
On Thu, Mar 10, 2011 at 3:49 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Now, I admit that it's a git usability bug: for normal "git commit",
> git will _force_ you to write a message, and sadly, for merges, I made
> it instead just do the message automatically. My bad. I designed it
> for the kind of merges I do, where the the automatic merge message
> actually tells you what the merge is all about.
Btw, the reason I got really upset this time (and I've let it slide
before), is that this time your back-merge not only had that totally
useless merge message (that's happened before), but *because* you did
that back-merge, it also ends up making _my_ merge message totally
useless - the one that normally contains good and useful information
(a valid source of merging, and the abbreviated shortlog of what was
merged).
Why? Because you had done the back-merge very recently, my pull
request then ends up being a fast-forward, so your _useless_ merge
message basically entirely replaces the one that would have been
useful.
Yes, I could do it with "git pull --no-ff", but I have to admit to
hating adding more artificial merges into the tree just to get the
merge information. I didn't think the "--no-ff" flag was a good idea,
and I've never used it so far, but I have to say that now I'm
wavering.
I probably also should just talk to Junio and tell him that the whole
"totally automatic merge messages" was another horrible design
mistake. But if we do fix that in git, I suspect it will (a) break
scripts that expected the automatic silent merge and (b) take a long
time to percolate to people. So it might be one of those "we have to
live with it due to backwards compatibility reasons". Ugh.
Linus
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/7] be2net: Checksum field valid only for TCP/UDP
From: Ram Pai @ 2011-03-11 0:05 UTC (permalink / raw)
To: Padmanabh Ratnakar; +Cc: netdev, davem, Sathya Perla, Subramanian Seetharaman
In-Reply-To: <79e10ac8-3f25-4ee2-9a0d-08d39cd9fe9c@exht1.ad.emulex.com>
On Mon, Mar 07, 2011 at 06:38:16PM +0530, Padmanabh Ratnakar wrote:
> L4 checksum field is valid only for TCP/UDP packets in Lancer
>
> Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> Signed-off-by: Subramanian Seetharaman <subbu.seetharaman@emulex.com>
> ---
> drivers/net/benet/be_main.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
> index bf34434..ac7ae21 100644
> --- a/drivers/net/benet/be_main.c
> +++ b/drivers/net/benet/be_main.c
> @@ -865,14 +865,17 @@ static void be_rx_stats_update(struct be_rx_obj *rxo,
>
> static inline bool csum_passed(struct be_eth_rx_compl *rxcp)
> {
> - u8 l4_cksm, ipv6, ipcksm;
> + u8 l4_cksm, ipv6, ipcksm, tcpf, udpf;
>
> l4_cksm = AMAP_GET_BITS(struct amap_eth_rx_compl, l4_cksm, rxcp);
> ipcksm = AMAP_GET_BITS(struct amap_eth_rx_compl, ipcksm, rxcp);
> ipv6 = AMAP_GET_BITS(struct amap_eth_rx_compl, ip_version, rxcp);
> + tcpf = AMAP_GET_BITS(struct amap_eth_rx_compl, tcpf, rxcp);
> + udpf = AMAP_GET_BITS(struct amap_eth_rx_compl, udpf, rxcp);
>
> - /* Ignore ipcksm for ipv6 pkts */
> - return l4_cksm && (ipcksm || ipv6);
> + /* L4 checksum is not reliable for non TCP/UDP packets.
> + * Also ignore ipcksm for ipv6 pkts */
> + return (tcpf || udpf) && l4_cksm && (ipcksm || ipv6);
Is it invalid for non-Lancer too ? if not, then should'nt the
above condition be applied only for lancer?
RP
^ permalink raw reply
* Re: [PATCH 3/8] macb: convert printk to pr_ and friends
From: Jamie Iles @ 2011-03-11 0:09 UTC (permalink / raw)
To: Joe Perches; +Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <1299797284.20104.162.camel@Joe-Laptop>
On Thu, Mar 10, 2011 at 02:48:04PM -0800, Joe Perches wrote:
> On Thu, 2011-03-10 at 10:10 +0000, Jamie Iles wrote:
> > macb is already using the dev_dbg() and friends helpers so use pr_foo()
> > along with a pr_fmt() definition to make the printing a little cleaner.
> > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
>
> Hi Jamie.
>
> Because these conversions use a struct net_device,
> they would be better as:
>
> netdev_<foo>(struct net_device *dev, const char *fmt, ...)
Ahh nice, I hadn't come across those before. I'll update all of the
pr_* and dev_* statements to use the netdev variants.
Thanks for that!
Jamie
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-11 0:29 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20110310.155556.48513201.davem@davemloft.net>
On Thu, Mar 10, 2011 at 3:55 PM, David Miller <davem@davemloft.net> wrote:
> I should have put:
>
> Merge to get commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b
> ("net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules")
> so that we can add Stephen Hemminger's fix to handle ip6 tunnels
> as well, which uses the MODULE_ALIAS_NETDEV() macro created by
> that change.
Yeah, that would have explained it. That said, if you are merging for
something like that, may I suggest actually starting off with
git merge 8909c9ad8ff03611c9c96c9a92656213e4bb495b
that then actually makes the history itself also show the relationship
(you'd still have to write the commit message explaining why,
otherwise git will try to be "helpful" by making the merge commit
message be
Merge commit '8909c9ad8ff03611c9c96c9a92656213e4bb495b'
which while _technically_ more useful and indicative of what you
wanted to do isn't actually any more readable than the one you have
now.
But the reason it would have been better is that it would literally
have made the git commit parenthood point to the commit you actually
care about.
Of course, since 'gitk' ends up highlighting the SHA1 pointers in the
commit message, even just mentioning it in the message is often almost
equivalent to having the parenthood be explicit. But it would show in
the actual history graph too, which I think would have been a good
thing.
Oh well. Water under the bridge. I think I'll try --no-ff this once,
despite my misgivings about the concept.
Linus
[ The reason I don't like "--no-ff" is that it can cause endless "I'm
going to add my own merge message" wars where people want to write
their name in the snow, and then doing cross-merges doesn't ever
actually converge on a single end-result. Fast-forward merges means
that people merging back-and-forth will always end up converging.
But I guess the whole notion of "upstream" vs "downstream" is the
thing that should be considered to be the real way to avoid that, and
if a project cannot agree on what's upstream and what is downstream, I
suspect the project has deeper problems than a few extra merge
messages ;^) ]
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-11 0:34 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <AANLkTik3AyFTNoytebmOOZ=JSFMkt0bw7au-CSncUHJu@mail.gmail.com>
On Thu, Mar 10, 2011 at 4:29 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Oh well. Water under the bridge. I think I'll try --no-ff this once,
> despite my misgivings about the concept.
Oh wow. That really does end up looking odd. I know some other git
projects use --no-ff, but I don't think we've ever had them in the
kernel, and I've never see the graph look like that before.
But it did allow me to add an explanation for what happened, so maybe
it's worth it.
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2011-03-11 0:34 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <AANLkTik3AyFTNoytebmOOZ=JSFMkt0bw7au-CSncUHJu@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 10 Mar 2011 16:29:30 -0800
> On Thu, Mar 10, 2011 at 3:55 PM, David Miller <davem@davemloft.net> wrote:
>> I should have put:
>>
>> Merge to get commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b
>> ("net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules")
>> so that we can add Stephen Hemminger's fix to handle ip6 tunnels
>> as well, which uses the MODULE_ALIAS_NETDEV() macro created by
>> that change.
>
> Yeah, that would have explained it. That said, if you are merging for
> something like that, may I suggest actually starting off with
>
> git merge 8909c9ad8ff03611c9c96c9a92656213e4bb495b
>
> that then actually makes the history itself also show the relationship
> (you'd still have to write the commit message explaining why,
> otherwise git will try to be "helpful" by making the merge commit
> message be
>
> Merge commit '8909c9ad8ff03611c9c96c9a92656213e4bb495b'
>
> which while _technically_ more useful and indicative of what you
> wanted to do isn't actually any more readable than the one you have
> now.
>
> But the reason it would have been better is that it would literally
> have made the git commit parenthood point to the commit you actually
> care about.
So, this is like a cherry-pick of sorts that doesn't create new commits?
It just makes the merge commit, and that's where I explain why I need this
particular change in my tree.
Right?
^ permalink raw reply
* Re: [GIT] Networking
From: Dave Airlie @ 2011-03-11 0:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTiktUsR1vXo84H2m_tLZRgDGee+JdvxGZjX7hYMq@mail.gmail.com>
On Fri, Mar 11, 2011 at 10:34 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Mar 10, 2011 at 4:29 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Oh well. Water under the bridge. I think I'll try --no-ff this once,
>> despite my misgivings about the concept.
>
> Oh wow. That really does end up looking odd. I know some other git
> projects use --no-ff, but I don't think we've ever had them in the
> kernel, and I've never see the graph look like that before.
>
> But it did allow me to add an explanation for what happened, so maybe
> it's worth it.
I didn't realise we weren't meant to --no-ff, I've been lately using
--no-ff --log
so I can keep track of what I merged easier, when someone bases something on my
tree and I haven't moved it in a while.
Though I suppose author/committer info should tell me this I've found
having the logs
at least a bit useful.
Dave.
^ permalink raw reply
* [PATCH] ipv4: Remove redundant RCU locking in ip_check_mc().
From: David Miller @ 2011-03-11 0:43 UTC (permalink / raw)
To: netdev
All callers are under rcu_read_lock() protection already.
Rename to ip_check_mc_rcu() to make it even more clear.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/igmp.h | 2 +-
net/ipv4/igmp.c | 5 ++---
net/ipv4/route.c | 8 ++++----
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/include/linux/igmp.h b/include/linux/igmp.h
index 74cfcff..82de336 100644
--- a/include/linux/igmp.h
+++ b/include/linux/igmp.h
@@ -217,7 +217,7 @@ struct ip_mc_list {
#define IGMPV3_QQIC(value) IGMPV3_EXP(0x80, 4, 3, value)
#define IGMPV3_MRC(value) IGMPV3_EXP(0x80, 4, 3, value)
-extern int ip_check_mc(struct in_device *dev, __be32 mc_addr, __be32 src_addr, u16 proto);
+extern int ip_check_mc_rcu(struct in_device *dev, __be32 mc_addr, __be32 src_addr, u16 proto);
extern int igmp_rcv(struct sk_buff *);
extern int ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr);
extern int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr);
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 44ba906..12b65cc 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -2333,13 +2333,13 @@ void ip_mc_drop_socket(struct sock *sk)
rtnl_unlock();
}
-int ip_check_mc(struct in_device *in_dev, __be32 mc_addr, __be32 src_addr, u16 proto)
+/* called with rcu_read_lock() */
+int ip_check_mc_rcu(struct in_device *in_dev, __be32 mc_addr, __be32 src_addr, u16 proto)
{
struct ip_mc_list *im;
struct ip_sf_list *psf;
int rv = 0;
- rcu_read_lock();
for_each_pmc_rcu(in_dev, im) {
if (im->multiaddr == mc_addr)
break;
@@ -2361,7 +2361,6 @@ int ip_check_mc(struct in_device *in_dev, __be32 mc_addr, __be32 src_addr, u16 p
} else
rv = 1; /* unspecified source; tentatively allow */
}
- rcu_read_unlock();
return rv;
}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index ac32d8f..f6730d9 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2309,8 +2309,8 @@ skip_cache:
struct in_device *in_dev = __in_dev_get_rcu(dev);
if (in_dev) {
- int our = ip_check_mc(in_dev, daddr, saddr,
- ip_hdr(skb)->protocol);
+ int our = ip_check_mc_rcu(in_dev, daddr, saddr,
+ ip_hdr(skb)->protocol);
if (our
#ifdef CONFIG_IP_MROUTE
||
@@ -2368,8 +2368,8 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
fi = NULL;
} else if (type == RTN_MULTICAST) {
flags |= RTCF_MULTICAST | RTCF_LOCAL;
- if (!ip_check_mc(in_dev, oldflp->fl4_dst, oldflp->fl4_src,
- oldflp->proto))
+ if (!ip_check_mc_rcu(in_dev, oldflp->fl4_dst, oldflp->fl4_src,
+ oldflp->proto))
flags &= ~RTCF_LOCAL;
/* If multicast route do not exist use
* default one, but do not gateway in this case.
--
1.7.4.1
^ permalink raw reply related
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-11 0:51 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20110310.163434.260095615.davem@davemloft.net>
On Thu, Mar 10, 2011 at 4:34 PM, David Miller <davem@davemloft.net> wrote:
>
> So, this is like a cherry-pick of sorts that doesn't create new commits?
> It just makes the merge commit, and that's where I explain why I need this
> particular change in my tree.
>
> Right?
No, it's really just a perfectly regular merge. It's just that instead
of "merge whatever random state that Linus' tree happened to be in, in
order to get that one commit I wanted", it instead does a "merge the
_particular_ history that led up to the one commit I want".
So it's still a back-merge, and in that sense it is technically
absolutely no different from your "merge master" thing. You'll be
merging not just that one commit, but all the parents of the commit
too. So it's not like a cherry-pick, that literally just takes that
one single commit. You do get history, the same way you get with any
merge.
The reason I would suggest doing the "pick explicitly" is just that it
- at least to me - makes it much clearer *what* you actually wanted to
do. It's really the explicitness of "I need that particular commit" vs
"I just want to get whatever Linus has, because he ended up merging a
thing I wanted".
Put another way, I want merging to be something people think about,
and have a clear reason for. Now, for a regular upstream merge, that
"clear reason" is so obvious that we never even discuss it: most of
the merges in the kernel tree have a very simple reason, that simply
goes as "submaintainer asked for his tree to be merged". That's such
an obvious thing that we don't write it out - and it's why I
(stupidly) thought that "git merge" and "git pull" can just generate
the merge messages automatically.
But in other cases, there are less obvious reasons for why a merge
happens, and it's usually a case of a back-merge (ie a submaintainer
merging from upstream, rather than upstream merging from a
submaintainer). Now, there are various good reasons for those kinds of
merges too, and the automated git messages are all usually totally
useless for that case.
The reasons can be any of:
- "I don't want to get too far away from upstream". This is very
understandable, but I have asked people to please _not_ merge "random
trees of the day". Please use major releases for this (or, if worst
comes to worst, -rc releases) rather than just do something else.
- "I need the functionality that went upstream, and I don't want to
duplicate it". This was your case, and again, it's entirely
understandable. It's just that I think it should be explained, so that
people who see the merge also see _why_ the merge was done. And again,
I don't like seeing "merge random tree of the day". There should
really be some explicit thought about _why_ the merge is needed, and
if you merge a tree because you need a particular state, then I think
you should merge _that_ tree, not just "whatever Linus happened to
have right then".
I basically think "merge random tree" is _always_ wrong.
And I do admit that it's a big design mistake in git to not force
people to think about things, and to make it much too easy to generate
useless merge messages. As mentioned, that whole automatic merge
message thing makes a _lot_ more sense to upstream than it does to
downstream: when you're merging from a submaintainer, the implicit
fact that downstream _asked_ you to merge is what makes the automatic
message actually worth something.
Put another way: the same way I think it's wrong when you merge some
random tree from me, I think it would be very wrong for me to merge
your random tree of the day. That would be crazy - who knows what the
heck you have in your tree, and unless you ask me to merge, I should
just assume that it's broken. You may be in the middle of some
development thing, and your tree may be totally broken. I shouldn't
pull it.
The same is true the other way around. Sure, especially late in the
-rc cycle, you can hopefully assume that my tree isn't crap, but even
so, I would really like people to think about _what_ they are merging.
And making it explicit is a good thing, I think.
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-03-11 0:57 UTC (permalink / raw)
To: Dave Airlie; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTikiy+hNgG=BRWKkHEHCdvJnffWP6nhp1XxsEEO+@mail.gmail.com>
On Thu, Mar 10, 2011 at 4:40 PM, Dave Airlie <airlied@gmail.com> wrote:
>
> I didn't realise we weren't meant to --no-ff, I've been lately using
> --no-ff --log
> so I can keep track of what I merged easier, when someone bases something on my
> tree and I haven't moved it in a while.
Well, the whole "--no-ff --log" is really designed for exactly that.
It's the "I'm the upstream maintainer, and I want that nice merge
summary". And it really is useful for that.
So I don't know about "weren't meant to". It very much is why those
flags exist (I don't personally use "--log", but that's because since
I'm the very top maintainer I've just set the flag in my .git/config
flag that makes _all_ my merges logging merges).
It's just that when I started doing git, the fast-forward merge was
very much a design decision. But I have to admit that I really like my
merge summaries too, and the main reason I have never really
considered using --no-ff is that _my_ tree moves so often that
practically speaking, I never fast-forward. If I get a fast-forward
merge, it almost always means that some submaintainer did something
iffy (like rebase his tree), and that the commits from that
submaintainer haven't been around for very long.
So no, I don't think you've been wrong in using "--no-ff --log". It
does make sense.
I just have my own private hang-ups about why I'm not personally a
huge fan of --no-ff.
But now that I've done it once, maybe I'm hooked. It's like coke to
Charlie Sheen.
Linus
^ permalink raw reply
* [PATCH 1/2] ipv4: Kill flowi arg to fib_select_multipath()
From: David Miller @ 2011-03-11 1:04 UTC (permalink / raw)
To: netdev
Completely unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/ip_fib.h | 2 +-
net/ipv4/fib_semantics.c | 2 +-
net/ipv4/route.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index 3f6c943..d948e23 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -230,7 +230,7 @@ extern int fib_sync_down_dev(struct net_device *dev, int force);
extern int fib_sync_down_addr(struct net *net, __be32 local);
extern void fib_update_nh_saddrs(struct net_device *dev);
extern int fib_sync_up(struct net_device *dev);
-extern void fib_select_multipath(const struct flowi *flp, struct fib_result *res);
+extern void fib_select_multipath(struct fib_result *res);
/* Exported by fib_trie.c */
extern void fib_trie_init(void);
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index d73d758..b5d523b 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1210,7 +1210,7 @@ int fib_sync_up(struct net_device *dev)
* The algorithm is suboptimal, but it provides really
* fair weighted route distribution.
*/
-void fib_select_multipath(const struct flowi *flp, struct fib_result *res)
+void fib_select_multipath(struct fib_result *res)
{
struct fib_info *fi = res->fi;
int w;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 336a38f..e72279e 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1319,7 +1319,7 @@ static int ip_mkroute_input(struct sk_buff *skb,
#ifdef CONFIG_IP_ROUTE_MULTIPATH
if (res->fi && res->fi->fib_nhs > 1)
- fib_select_multipath(fl, res);
+ fib_select_multipath(res);
#endif
/* create a routing cache entry */
@@ -1803,7 +1803,7 @@ struct rtable *__ip_route_output_key(struct net *net, struct flowi *fl)
#ifdef CONFIG_IP_ROUTE_MULTIPATH
if (res.fi->fib_nhs > 1 && fl.oif == 0)
- fib_select_multipath(fl, &res);
+ fib_select_multipath(&res);
else
#endif
if (!res.prefixlen && res.type == RTN_UNICAST && !fl->oif)
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/2] ipv4: Remove unnecessary test from ip_mkroute_input()
From: David Miller @ 2011-03-11 1:05 UTC (permalink / raw)
To: netdev
fl->oif will always be zero on the input path, so there is no reason
to test for that.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/route.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index f6730d9..a7ac90c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2047,7 +2047,7 @@ static int ip_mkroute_input(struct sk_buff *skb,
unsigned hash;
#ifdef CONFIG_IP_ROUTE_MULTIPATH
- if (res->fi && res->fi->fib_nhs > 1 && fl->oif == 0)
+ if (res->fi && res->fi->fib_nhs > 1)
fib_select_multipath(fl, res);
#endif
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 1/8] macb: unify at91 and avr32 platform data
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-11 1:41 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, Nicolas Ferre, linux-arm-kernel
In-Reply-To: <20110310131724.GG6198@pulham.picochip.com>
On 13:17 Thu 10 Mar , Jamie Iles wrote:
> On Thu, Mar 10, 2011 at 02:06:04PM +0100, Nicolas Ferre wrote:
> > On 3/10/2011 11:10 AM, Jamie Iles :
> > > --- a/drivers/net/macb.c
> > > +++ b/drivers/net/macb.c
> > > @@ -18,12 +18,10 @@
> > > #include <linux/netdevice.h>
> > > #include <linux/etherdevice.h>
> > > #include <linux/dma-mapping.h>
> > > +#include <linux/platform_data/macb.h>
> > > #include <linux/platform_device.h>
> > > #include <linux/phy.h>
> > >
> > > -#include <mach/board.h>
> > > -#include <mach/cpu.h>
> >
> > I did not bouble check but do we need no more cpu_is_ macros?
>
> No, I couldn't see any in there and it builds for all of the AT91
> targets and all of the AVR32 ones that I tried. I can't see any macros
> in there that are likely to use cpu_is_* internally either.
keep as we need to remove the #ifdef AT91 to cpu_is
I've patch for this
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 2/8] macb: detect hclk presence from platform data
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-11 1:44 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, nicolas.ferre, linux-arm-kernel
In-Reply-To: <1299751843-9743-3-git-send-email-jamie@jamieiles.com>
On 10:10 Thu 10 Mar , Jamie Iles wrote:
> Rather than detecting whether we need to do a clk_get() and enable on
> the "hclk" based on the kernel configuration, add an extra field to the
> platform data. This makes it cleaner to add more supported
> architectures without lots of ifdeffery.
>
> This requires that all instantiations of the device have platform data
> defined but that is the case currently anyway.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> ---
> arch/avr32/mach-at32ap/at32ap700x.c | 2 +
> drivers/net/macb.c | 77 ++++++++++++++++++-----------------
> include/linux/platform_data/macb.h | 1 +
> 3 files changed, 43 insertions(+), 37 deletions(-)
>
> diff --git a/arch/avr32/mach-at32ap/at32ap700x.c b/arch/avr32/mach-at32ap/at32ap700x.c
> index 2747cde..2abcafd 100644
> --- a/arch/avr32/mach-at32ap/at32ap700x.c
> +++ b/arch/avr32/mach-at32ap/at32ap700x.c
> @@ -1088,6 +1088,8 @@ at32_add_device_eth(unsigned int id, struct eth_platform_data *data)
> struct platform_device *pdev;
> u32 pin_mask;
>
> + data->have_hclk = 1;
> +
> switch (id) {
> case 0:
> pdev = &macb0_device;
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index bfd3601..ae98fee 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -246,9 +246,7 @@ static int macb_mii_init(struct macb *bp)
> bp->mii_bus->parent = &bp->dev->dev;
> pdata = bp->pdev->dev.platform_data;
>
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> -
> + bp->mii_bus->phy_mask = pdata->phy_mask;
> bp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
> if (!bp->mii_bus->irq) {
> err = -ENOMEM;
> @@ -1103,9 +1101,14 @@ static const struct net_device_ops macb_netdev_ops = {
> #endif
> };
>
> +#ifdef CONFIG_ARCH_AT91
> +#define PCLK_NAME "macb_clk"
> +#else /* CONFIG_ARCH_AT91 */
> +#define PCLK_NAME "pclk"
> +#endif
we need change the clock name and avoid the ifdef
so this will be generic
nb I work on the switch to clkdev currently for avr32 and at91
Best Regards,
J.
^ permalink raw reply
* how to utilize multi tx queue to sent packets?
From: zhou rui @ 2011-03-11 1:44 UTC (permalink / raw)
To: netdev
hi
I am doing some test according to the
website:http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap
use packet_mmap tx_ring to send packet.
I modified the sample code "packetmmap.c" to make it send packets have
different outer ip.
so that with the help of RSS, I can achieve higher throughput.
but one thing I saw at the tx side, is that all the packets are sent
via the same tx_queue,which is conflict with what I saw at the rx
side.
any idea to make it sent packets via different tx_queues? (spread
across the tx_queues)
thanks
jon
^ permalink raw reply
* Re: [PATCH] Make CUBIC Hystart more robust to RTT variations
From: Bill Fink @ 2011-03-11 2:25 UTC (permalink / raw)
To: Lucas Nussbaum
Cc: Stephen Hemminger, Injong Rhee, David Miller, xiyou wangcong,
netdev, sangtae ha
In-Reply-To: <20110310085433.GA11953@xanadu.blop.info>
On Thu, 10 Mar 2011, Lucas Nussbaum wrote:
> On 10/03/11 at 02:17 -0500, Bill Fink wrote:
> > On Wed, 9 Mar 2011, Stephen Hemminger wrote:
> >
> > > Bill what is the HZ in your kernel config.
> > > I am concerned hystart doesn't work well with HZ=100
> >
> > HZ=1000
> >
> > But I did have tcp_timestamps disabled. Should I re-run
> > the tests with tcp_timestamps enabled?
>
> I ran my tests with timestamps enabled and HZ=250. If you have the
> opportunity to run tests in the same config, it would be great. The
> HZ=250 vs HZ=1000 difference could explain why it's working.
>
> However, enabling or disabling timestamps shouldn't make a difference,
> since the hystart code doesn't use TCP_CONG_RTT_STAMP.
I reran the same tests with HZ=250 and tcp_timestamps enabled.
BTW all my tests are with 9000-byte jumbo frames. If you want,
I can also try them using standard 1500-byte Ethernet frames.
First on the 18 ms RTT path:
8 GB transfer across an 18 ms RTT path with autotuning and hystart:
i7test7% nuttcp -n8g -i1 192.168.1.23
614.5625 MB / 1.00 sec = 5155.1383 Mbps 0 retrans
824.2500 MB / 1.00 sec = 6914.5038 Mbps 0 retrans
826.6875 MB / 1.00 sec = 6934.5632 Mbps 0 retrans
831.5625 MB / 1.00 sec = 6975.7146 Mbps 0 retrans
835.1875 MB / 1.00 sec = 7006.1867 Mbps 0 retrans
844.8125 MB / 1.00 sec = 7086.7867 Mbps 0 retrans
862.1250 MB / 1.00 sec = 7231.9274 Mbps 0 retrans
886.5625 MB / 1.00 sec = 7437.0402 Mbps 0 retrans
918.6875 MB / 1.00 sec = 7706.5633 Mbps 0 retrans
8192.0000 MB / 9.80 sec = 7009.7460 Mbps 12 %TX 31 %RX 0 retrans 18.91 msRTT
Ramps up quickly to a little under 7 Gbps, then increases more
slowly to 7.7 Gbps, with no TCP retransmissions. Actually performed
somewhat better than the HZ=1000 case.
8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and hystart:
i7test7% nuttcp -n8g -i1 -w40m 192.168.1.23
716.0000 MB / 1.00 sec = 6006.0812 Mbps 0 retrans
864.5000 MB / 1.00 sec = 7251.9589 Mbps 0 retrans
866.1250 MB / 1.00 sec = 7265.4596 Mbps 0 retrans
871.1250 MB / 1.00 sec = 7307.7746 Mbps 0 retrans
875.6250 MB / 1.00 sec = 7345.2308 Mbps 0 retrans
886.1875 MB / 1.00 sec = 7433.8796 Mbps 0 retrans
904.1250 MB / 1.00 sec = 7584.3654 Mbps 0 retrans
929.1875 MB / 1.00 sec = 7794.4728 Mbps 0 retrans
961.6250 MB / 1.00 sec = 8066.7839 Mbps 0 retrans
8192.0000 MB / 9.34 sec = 7356.7856 Mbps 13 %TX 32 %RX 0 retrans 18.92 msRTT
Ramps up quickly to 7+ Gbps, then increases more slowly to 8+ Gbps,
with no TCP retransmissions. Performed significantly worse than
the HZ=1000 case.
8 GB transfer across an 18 ms RTT path with autotuning and no hystart:
i7test7% nuttcp -n8g -i1 192.168.1.23
850.8750 MB / 1.00 sec = 7137.3642 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.3396 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.5486 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.5883 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.0621 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.4396 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.5189 Mbps 0 retrans
8192.0000 MB / 7.23 sec = 9499.4276 Mbps 17 %TX 40 %RX 0 retrans 18.95 msRTT
Quickly ramps up to full 10-GigE line rate, with no TCP retrans.
Same performance as HZ=1000 case.
8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and no hystart:
i7test7% nuttcp -n8g -i1 -w40m 192.168.1.23
969.8125 MB / 1.00 sec = 8135.2793 Mbps 0 retrans
1181.1250 MB / 1.00 sec = 9908.0541 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.1810 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.9044 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.0729 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.0532 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.9549 Mbps 0 retrans
8192.0000 MB / 7.15 sec = 9609.9893 Mbps 17 %TX 41 %RX 0 retrans 18.92 msRTT
Also quickly ramps up to full 10-GigE line rate, with no TCP retrans.
Same performance as HZ=1000 case.
Now trying the same type of tests across an 80 ms RTT path.
8 GB transfer across an 80 ms RTT path with autotuning and hystart:
i7test7% nuttcp -n8g -i1 192.168.1.18
10.6250 MB / 1.00 sec = 89.1274 Mbps 0 retrans
501.7500 MB / 1.00 sec = 4208.6979 Mbps 0 retrans
872.9375 MB / 1.00 sec = 7323.2651 Mbps 0 retrans
865.5000 MB / 1.00 sec = 7259.8901 Mbps 0 retrans
854.9375 MB / 1.00 sec = 7172.0224 Mbps 0 retrans
872.0000 MB / 1.00 sec = 7314.8735 Mbps 0 retrans
866.6875 MB / 1.00 sec = 7270.3017 Mbps 0 retrans
855.1250 MB / 1.00 sec = 7172.9354 Mbps 0 retrans
868.7500 MB / 1.00 sec = 7288.1352 Mbps 0 retrans
868.3750 MB / 1.00 sec = 7283.8238 Mbps 0 retrans
8192.0000 MB / 10.99 sec = 6250.8745 Mbps 11 %TX 25 %RX 0 retrans 80.78 msRTT
Similar to the 20 ms RTT path, but achieving somewhat lower
performance levels, presumably due to the larger RTT. Ramps
up fairly quickly to 7+ Gbps, then appears to stabilize at
that level, with no TCP retransmissions. Somewhat better
performance than the HZ=1000 case.
8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and hystart:
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.8125 MB / 1.00 sec = 870.8197 Mbps 0 retrans
1071.6875 MB / 1.00 sec = 8989.8315 Mbps 0 retrans
1089.6250 MB / 1.00 sec = 9140.6929 Mbps 0 retrans
1093.4375 MB / 1.00 sec = 9172.4186 Mbps 0 retrans
1095.1875 MB / 1.00 sec = 9187.1262 Mbps 0 retrans
1094.7500 MB / 1.00 sec = 9183.3460 Mbps 0 retrans
1097.8750 MB / 1.00 sec = 9208.9431 Mbps 0 retrans
1103.9375 MB / 1.00 sec = 9261.2584 Mbps 0 retrans
8192.0000 MB / 8.48 sec = 8102.4984 Mbps 15 %TX 38 %RX 0 retrans 80.81 msRTT
Quickly ramps up to 9 Gbps and then slowly increases further,
with no TCP retrans. Basically same performance as HZ=1000 case.
8 GB transfer across an 80 ms RTT path with autotuning and no hystart:
i7test7% nuttcp -n8g -i1 192.168.1.18
10.0000 MB / 1.00 sec = 83.8847 Mbps 0 retrans
482.3125 MB / 1.00 sec = 4045.8172 Mbps 0 retrans
863.2500 MB / 1.00 sec = 7241.4224 Mbps 0 retrans
874.3750 MB / 1.00 sec = 7334.7304 Mbps 0 retrans
855.0000 MB / 1.00 sec = 7172.3889 Mbps 0 retrans
863.6250 MB / 1.00 sec = 7244.6840 Mbps 0 retrans
875.0625 MB / 1.00 sec = 7340.5489 Mbps 0 retrans
855.1875 MB / 1.00 sec = 7173.6390 Mbps 0 retrans
863.8750 MB / 1.00 sec = 7246.9044 Mbps 0 retrans
873.3125 MB / 1.00 sec = 7325.9788 Mbps 0 retrans
8192.0000 MB / 10.99 sec = 6253.7478 Mbps 11 %TX 26 %RX 0 retrans 80.80 msRTT
Ramps up quickly to 7+ Gbps, then appears to stabilize at that
level, with no TCP retransmissions. Performance is same as
with autotuning enabled, but less than using a manually set
100 MB socket buffer. Same performance as HZ=1000 case.
8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and no hystart:
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.8125 MB / 1.00 sec = 870.7945 Mbps 0 retrans
1148.4375 MB / 1.00 sec = 9633.6860 Mbps 0 retrans
1176.9375 MB / 1.00 sec = 9872.7291 Mbps 0 retrans
1088.1250 MB / 1.00 sec = 9127.4342 Mbps 39 retrans
171.0625 MB / 1.00 sec = 1435.1370 Mbps 0 retrans
901.0625 MB / 1.00 sec = 7558.3275 Mbps 0 retrans
1160.0625 MB / 1.00 sec = 9731.1831 Mbps 0 retrans
1172.5625 MB / 1.00 sec = 9836.5508 Mbps 0 retrans
1085.0625 MB / 1.00 sec = 9101.2174 Mbps 31 retrans
150.3750 MB / 1.00 sec = 1261.5908 Mbps 2 retrans
28.1875 MB / 1.00 sec = 236.4544 Mbps 0 retrans
8192.0000 MB / 11.31 sec = 6077.0651 Mbps 14 %TX 29 %RX 72 retrans 80.82 msRTT
As in the HZ=1000 case, disabling hystart on a large RTT path
does not seem to play nice with a manually specified socket buffer,
resulting in TCP retransmissions that limit the effective network
performance. Performance seems similar to the HZ=1000 case.
This is a repeatable phenomenon, but didn't seem quite as
variable as in the HZ=1000 case (but probably need a larger
number of repetitions to draw any firm conclusions about that).
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.4375 MB / 1.00 sec = 867.6472 Mbps 0 retrans
1143.0625 MB / 1.00 sec = 9589.1347 Mbps 0 retrans
629.4375 MB / 1.00 sec = 5280.0886 Mbps 24 retrans
164.8750 MB / 1.00 sec = 1383.0759 Mbps 0 retrans
1121.6250 MB / 1.00 sec = 9408.7878 Mbps 0 retrans
1168.1250 MB / 1.00 sec = 9799.0309 Mbps 0 retrans
1167.5000 MB / 1.00 sec = 9793.5725 Mbps 0 retrans
1165.9375 MB / 1.00 sec = 9780.0841 Mbps 0 retrans
959.8750 MB / 1.00 sec = 8052.4902 Mbps 9 retrans
568.1250 MB / 1.00 sec = 4765.8065 Mbps 0 retrans
8192.0000 MB / 10.03 sec = 6852.2803 Mbps 13 %TX 32 %RX 33 retrans 80.81 msRTT
And:
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.8125 MB / 1.00 sec = 870.8241 Mbps 0 retrans
1148.8125 MB / 1.00 sec = 9636.9570 Mbps 0 retrans
1177.3750 MB / 1.00 sec = 9876.4287 Mbps 0 retrans
1177.4375 MB / 1.00 sec = 9877.0024 Mbps 0 retrans
693.5000 MB / 1.00 sec = 5817.6335 Mbps 36 retrans
263.4375 MB / 1.00 sec = 2209.7701 Mbps 0 retrans
1137.3125 MB / 1.00 sec = 9540.7263 Mbps 0 retrans
1169.9375 MB / 1.00 sec = 9814.2354 Mbps 0 retrans
1168.6875 MB / 1.00 sec = 9803.7005 Mbps 0 retrans
8192.0000 MB / 9.21 sec = 7460.8789 Mbps 14 %TX 34 %RX 36 retrans 80.81 msRTT
Re-enabling hystart immediately gives a clean test with no TCP retrans.
i7test7% nuttcp -n8g -i1 -w100m 192.168.1.18
103.8125 MB / 1.00 sec = 870.8075 Mbps 0 retrans
1072.3125 MB / 1.00 sec = 8995.0653 Mbps 0 retrans
1089.4375 MB / 1.00 sec = 9139.0926 Mbps 0 retrans
1093.1875 MB / 1.00 sec = 9170.0646 Mbps 0 retrans
1095.5625 MB / 1.00 sec = 9190.3914 Mbps 0 retrans
1095.5000 MB / 1.00 sec = 9189.8303 Mbps 0 retrans
1097.6875 MB / 1.00 sec = 9207.8952 Mbps 0 retrans
1104.1875 MB / 1.00 sec = 9262.5405 Mbps 0 retrans
8192.0000 MB / 8.48 sec = 8104.4831 Mbps 15 %TX 38 %RX 0 retrans 80.77 msRTT
-Bill
Previous HZ=1000 tests (with tcp_timestamps disabled):
Here are some tests I performed across real networks, where
congestion is generally not an issue, with a 2.6.35 kernel on
the transmit side.
8 GB transfer across an 18 ms RTT path with autotuning and hystart:
i7test7% nuttcp -n8g -i1 192.168.1.23
517.9375 MB / 1.00 sec = 4344.6096 Mbps 0 retrans
688.4375 MB / 1.00 sec = 5775.1998 Mbps 0 retrans
692.9375 MB / 1.00 sec = 5812.7462 Mbps 0 retrans
698.0625 MB / 1.00 sec = 5855.8078 Mbps 0 retrans
699.8750 MB / 1.00 sec = 5871.0123 Mbps 0 retrans
710.5625 MB / 1.00 sec = 5960.5707 Mbps 0 retrans
728.8125 MB / 1.00 sec = 6113.7652 Mbps 0 retrans
751.3750 MB / 1.00 sec = 6302.9210 Mbps 0 retrans
783.8750 MB / 1.00 sec = 6575.6201 Mbps 0 retrans
825.1875 MB / 1.00 sec = 6921.8145 Mbps 0 retrans
875.4375 MB / 1.00 sec = 7343.9811 Mbps 0 retrans
8192.0000 MB / 11.26 sec = 6102.4718 Mbps 11 %TX 28 %RX 0 retrans 18.92 msRTT
Ramps up quickly to a little under 6 Gbps, then increases more
slowly to 7+ Gbps, with no TCP retransmissions.
8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and hystart:
i7test7% nuttcp -n8g -w40m -i1 192.168.1.23
970.0625 MB / 1.00 sec = 8136.8475 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9909.0045 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9908.6369 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.8747 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.0531 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9908.8153 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.0729 Mbps 0 retrans
8192.0000 MB / 7.13 sec = 9633.5814 Mbps 17 %TX 42 %RX 0 retrans 18.91 msRTT
Quickly ramps up to full 10-GigE line rate, with no TCP retrans.
8 GB transfer across an 18 ms RTT path with autotuning and no hystart:
i7test7% nuttcp -n8g -i1 192.168.1.23
845.4375 MB / 1.00 sec = 7091.5828 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9910.0134 Mbps 0 retrans
1181.0625 MB / 1.00 sec = 9907.1830 Mbps 0 retrans
1181.4375 MB / 1.00 sec = 9910.8936 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.1721 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.5774 Mbps 0 retrans
1181.1875 MB / 1.00 sec = 9908.6874 Mbps 0 retrans
8192.0000 MB / 7.25 sec = 9484.4524 Mbps 18 %TX 41 %RX 0 retrans 18.92 msRTT
Also quickly ramps up to full 10-GigE line rate, with no TCP retrans.
8 GB transfer across an 18 ms RTT path with 40 MB socket buffer and no hystart:
i7test7% nuttcp -n8g -w40m -i1 192.168.1.23
969.8750 MB / 1.00 sec = 8135.6571 Mbps 0 retrans
1181.3125 MB / 1.00 sec = 9909.3990 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9908.9342 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.4098 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9908.8252 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.0630 Mbps 0 retrans
1181.2500 MB / 1.00 sec = 9909.3504 Mbps 0 retrans
8192.0000 MB / 7.15 sec = 9611.8053 Mbps 18 %TX 42 %RX 0 retrans 18.95 msRTT
Basically the same as the case with 40 MB socket buffer and hystart enabled.
Now trying the same type of tests across an 80 ms RTT path.
8 GB transfer across an 80 ms RTT path with autotuning and hystart:
i7test7% nuttcp -n8g -i1 192.168.1.18
11.3125 MB / 1.00 sec = 94.8954 Mbps 0 retrans
441.5625 MB / 1.00 sec = 3704.1021 Mbps 0 retrans
687.3750 MB / 1.00 sec = 5765.8657 Mbps 0 retrans
715.5625 MB / 1.00 sec = 6002.6273 Mbps 0 retrans
709.9375 MB / 1.00 sec = 5955.5958 Mbps 0 retrans
691.3125 MB / 1.00 sec = 5799.0626 Mbps 0 retrans
718.6250 MB / 1.00 sec = 6028.3538 Mbps 0 retrans
718.0000 MB / 1.00 sec = 6023.0205 Mbps 0 retrans
704.0000 MB / 1.00 sec = 5905.5387 Mbps 0 retrans
733.3125 MB / 1.00 sec = 6151.4096 Mbps 0 retrans
738.8750 MB / 1.00 sec = 6198.2381 Mbps 0 retrans
731.8750 MB / 1.00 sec = 6139.3695 Mbps 0 retrans
8192.0000 MB / 12.85 sec = 5348.9677 Mbps 10 %TX 23 %RX 0 retrans 80.81 msRTT
Similar to the 20 ms RTT path, but achieving somewhat lower
performance levels, presumably due to the larger RTT. Ramps
up fairly quickly to a little under 6 Gbps, then increases
more slowly to 6+ Gbps, with no TCP retransmissions.
8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and hystart:
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
103.9375 MB / 1.00 sec = 871.8378 Mbps 0 retrans
1086.5625 MB / 1.00 sec = 9114.6102 Mbps 0 retrans
1106.6875 MB / 1.00 sec = 9283.5583 Mbps 0 retrans
1109.3125 MB / 1.00 sec = 9305.5226 Mbps 0 retrans
1111.1875 MB / 1.00 sec = 9321.9596 Mbps 0 retrans
1112.8125 MB / 1.00 sec = 9334.8452 Mbps 0 retrans
1113.6875 MB / 1.00 sec = 9341.6620 Mbps 0 retrans
1120.2500 MB / 1.00 sec = 9398.0054 Mbps 0 retrans
8192.0000 MB / 8.37 sec = 8207.2049 Mbps 16 %TX 38 %RX 0 retrans 80.81 msRTT
Quickly ramps up to 9+ Gbps and then slowly increases further,
with no TCP retrans.
8 GB transfer across an 80 ms RTT path with autotuning and no hystart:
i7test7% nuttcp -n8g -i1 192.168.1.18
11.2500 MB / 1.00 sec = 94.3703 Mbps 0 retrans
519.0625 MB / 1.00 sec = 4354.1596 Mbps 0 retrans
861.2500 MB / 1.00 sec = 7224.7970 Mbps 0 retrans
871.0000 MB / 1.00 sec = 7306.4191 Mbps 0 retrans
860.7500 MB / 1.00 sec = 7220.4438 Mbps 0 retrans
869.0625 MB / 1.00 sec = 7290.3340 Mbps 0 retrans
863.4375 MB / 1.00 sec = 7242.7707 Mbps 0 retrans
860.4375 MB / 1.00 sec = 7218.0606 Mbps 0 retrans
875.5000 MB / 1.00 sec = 7344.3071 Mbps 0 retrans
863.1875 MB / 1.00 sec = 7240.8257 Mbps 0 retrans
8192.0000 MB / 10.98 sec = 6259.4379 Mbps 12 %TX 27 %RX 0 retrans 80.81 msRTT
Ramps up quickly to 7+ Gbps, then appears to stabilize at that
level, with no TCP retransmissions. Performance is somewhat
better than with autotuning enabled, but less than using a
manually set 100 MB socket buffer.
8 GB transfer across an 80 ms RTT path with 100 MB socket buffer and no hystart:
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
102.8750 MB / 1.00 sec = 862.9487 Mbps 0 retrans
522.8750 MB / 1.00 sec = 4386.2811 Mbps 414 retrans
881.5625 MB / 1.00 sec = 7394.6534 Mbps 0 retrans
1164.3125 MB / 1.00 sec = 9766.6682 Mbps 0 retrans
1170.5625 MB / 1.00 sec = 9819.7042 Mbps 0 retrans
1166.8125 MB / 1.00 sec = 9788.2067 Mbps 0 retrans
1159.8750 MB / 1.00 sec = 9729.1530 Mbps 0 retrans
811.1250 MB / 1.00 sec = 6804.8017 Mbps 21 retrans
73.2500 MB / 1.00 sec = 614.4674 Mbps 0 retrans
884.6250 MB / 1.00 sec = 7420.2900 Mbps 0 retrans
8192.0000 MB / 10.34 sec = 6647.9394 Mbps 13 %TX 31 %RX 435 retrans 80.81 msRTT
Disabling hystart on a large RTT path does not seem to play nice with
a manually specified socket buffer, resulting in TCP retransmissions
that limit the effective network performance.
This is a repeatable but extremely variable phenomenon.
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
103.7500 MB / 1.00 sec = 870.3015 Mbps 0 retrans
1146.3750 MB / 1.00 sec = 9616.4520 Mbps 0 retrans
1175.9375 MB / 1.00 sec = 9864.6070 Mbps 0 retrans
615.6875 MB / 1.00 sec = 5164.7353 Mbps 21 retrans
139.2500 MB / 1.00 sec = 1168.1253 Mbps 0 retrans
1090.0625 MB / 1.00 sec = 9143.8053 Mbps 0 retrans
1170.4375 MB / 1.00 sec = 9818.6654 Mbps 0 retrans
1174.5625 MB / 1.00 sec = 9852.8754 Mbps 0 retrans
1174.8750 MB / 1.00 sec = 9855.6052 Mbps 0 retrans
8192.0000 MB / 9.42 sec = 7292.9879 Mbps 14 %TX 34 %RX 21 retrans 80.81 msRTT
And:
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
102.8125 MB / 1.00 sec = 862.4227 Mbps 0 retrans
1148.4375 MB / 1.00 sec = 9633.6860 Mbps 0 retrans
1177.4375 MB / 1.00 sec = 9877.3086 Mbps 0 retrans
1168.1250 MB / 1.00 sec = 9798.9133 Mbps 11 retrans
133.1250 MB / 1.00 sec = 1116.7457 Mbps 0 retrans
479.8750 MB / 1.00 sec = 4025.4631 Mbps 0 retrans
1150.6875 MB / 1.00 sec = 9652.4830 Mbps 0 retrans
1177.3125 MB / 1.00 sec = 9876.0624 Mbps 0 retrans
1177.3750 MB / 1.00 sec = 9876.0139 Mbps 0 retrans
320.2500 MB / 1.00 sec = 2686.6452 Mbps 19 retrans
64.9375 MB / 1.00 sec = 544.7363 Mbps 0 retrans
73.6250 MB / 1.00 sec = 617.6113 Mbps 0 retrans
8192.0000 MB / 12.39 sec = 5545.7570 Mbps 12 %TX 26 %RX 30 retrans 80.80 msRTT
Re-enabling hystart immediately gives a clean test with no TCP retrans.
i7test7% nuttcp -n8g -w100m -i1 192.168.1.18
103.8750 MB / 1.00 sec = 871.3353 Mbps 0 retrans
1086.7500 MB / 1.00 sec = 9116.4474 Mbps 0 retrans
1105.8125 MB / 1.00 sec = 9276.2276 Mbps 0 retrans
1109.4375 MB / 1.00 sec = 9306.5339 Mbps 0 retrans
1111.3125 MB / 1.00 sec = 9322.5327 Mbps 0 retrans
1111.3750 MB / 1.00 sec = 9322.8053 Mbps 0 retrans
1113.7500 MB / 1.00 sec = 9342.8962 Mbps 0 retrans
1120.3125 MB / 1.00 sec = 9397.5711 Mbps 0 retrans
8192.0000 MB / 8.38 sec = 8204.8394 Mbps 16 %TX 39 %RX 0 retrans 80.80 msRTT
^ 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