* Re: [PATCH] [1/1] Deprecate tcp_tw_{reuse,recycle}
From: Andi Kleen @ 2008-01-31 2:59 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <47A0CE75.5080200@candelatech.com>
On Wednesday 30 January 2008 20:22, Ben Greear wrote:
> We use these features to enable creating very high numbers of short-lived
> TCP connections, primarily used as a test tool for other network
> devices.
Hopefully these other network devices don't do any NAT then
or don't otherwise violate the IP-matches-PAWS assumption.
Most likely they do actually, so enabling TW recycle
for testing is probably not even safe for you.
Modern systems have a lot of RAM so even without tw recycle
you should be able to get a very high number of connections.
An timewait socket is around 128 bytes on 64bit; this means
with a GB of memory you can already support > 8 Million TW sockets.
On 32bit it's even more.
The optimization was originally written at a time when 64MB systems
were common.
If you don't care about data integrity have you considered just
using some custom UDP based protocol or run one of the user space
TCP stacks and disable all data integrity features? If you do care about
data integrity then you should probably disable tw recycle anyways.
The deprecation period will be some time (several months) so you'll have
enough time to migrate to another method
> Perhaps just document the adverse affects and/or have it print out a
> warning on the console whenever the feature is enabled?
"This feature is insecure and does not work on the internet or with NAT" ?
Somehow this just does not seem right to me.
-Andi
^ permalink raw reply
* Re: [PATCH retry] bluetooth : add conn add/del workqueues to avoid connection fail
From: Dave Young @ 2008-01-31 1:29 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: netdev, David Miller, bluez-devel, linux-kernel
In-Reply-To: <1201688462.6218.47.camel@violet>
On Jan 30, 2008 6:21 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Dave,
>
> > > The bluetooth hci_conn sysfs add/del executed in the default workqueue.
> > > If the del_conn is executed after the new add_conn with same target,
> > > add_conn will failed with warning of "same kobject name".
> > >
> > > Here add btaddconn & btdelconn workqueues,
> > > flush the btdelconn workqueue in the add_conn function to avoid the issue.
> > >
> > > Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
> >
> > This looks good, applied, thanks Dave.
> >
> > I've queued this up for 2.6.25 merging, if you want me to
> > schedule it for -stable, just let me know.
>
> don't include it. I first have to stress test it on one of my machines.
> Besides that I have to do some coding style cleanups.
Sorry, I thought you forgot it.
Thanks.
BTW, for the bus_id bug, If there's no urgent need I think we could do
the fix after driver core bus_id changes of kay which will be there
soon.
>
> Regards
>
> Marcel
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e"
From: Frans Pop @ 2008-01-31 1:26 UTC (permalink / raw)
To: Adrian Bunk
Cc: akpm, auke-jan.h.kok, davem, jeff, linux-kernel, netdev,
randy.dunlap, torvalds
In-Reply-To: <20080130235836.GV29368@does.not.exist>
Adrian Bunk wrote:
>> Jeff, Auke, would something like this be acceptable? It makes it very
>> obvious in the driver table which entries are for the PCIE versions that
>> would be handled by the E1000E driver if it is enabled..
>
> I don't like it:
> We should aim at having exactly one driver for one card.
There is one thing I don't understand, but that may well be just me...
>From Linus' original patch:
> +++ b/drivers/net/e1000/e1000_main.c
> + INTEL_E1000_ETHERNET_DEVICE(0x108C),
So, apparently support for 8086:108c was removed from the e1000 driver.
>From my lspci:
$ lspci -nn | grep Ether
01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) [8086:108c] (rev 03)
But when I look at where that card is sitting:
$ readlink pci/devices/0000\:01\:00.0/driver
../../../../bus/pci/drivers/e1000
So, it's on the PCI bus, not on the PCI-Express bus (which I also have, but
which has no devices on it).
Or does the e1000e driver also support cards on the PCI bus?
If that's the case then the original changelog entry "Move PCI-Express
device IDs over to e1000e" is misleading as it's not only PCI-Express
devices...
Hmmm. Or does which driver is loaded decide on which bus the device ends up?
Confused,
FJP
^ permalink raw reply
* Re: net-2.6.25 is no more...
From: David Miller @ 2008-01-31 0:36 UTC (permalink / raw)
To: dlezcano; +Cc: netdev
In-Reply-To: <47A0B62D.3080005@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Wed, 30 Jan 2008 18:38:53 +0100
> David Miller wrote:
> > From: Daniel Lezcano <dlezcano@fr.ibm.com>
> > Date: Wed, 30 Jan 2008 10:03:09 +0100
> >
> >> David Miller wrote:
> >>> Now that the bulk has been merged over and we are
> >>> actively working alongside Linus's tree I have moved
> >>> all current patch applying to net-2.6 instead of net-2.6.25,
> >>> so the current tree to use is:
> >>>
> >>> kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
> >> This tree is for fixes only, right ? or shall we send enhancement
> >> patches to net-2.6 until net-2.6.26 appears ?
> >
> > The latter.
>
> What will happen to the patches sent to net-2.6.25 a few days ago during
> the merge ? Should I resend them against net-2.6 ?
I have them in my backlog, so just be patient as even just doing
a read-only pass on my email while being here at LCA08 is super
painful.
^ permalink raw reply
* Re: [PATCH] Optimize cxgb3 xmit path (a bit)
From: Divy Le Ray @ 2008-01-31 0:04 UTC (permalink / raw)
To: Krishna Kumar; +Cc: jeff, netdev, davem
In-Reply-To: <20080130070016.29078.94125.sendpatchset@N20wks267652wss.in.ibm.com>
Krishna Kumar wrote:
> Changes:
> 1. Add common code for stopping queue.
> 2. No need to call netif_stop_queue followed by netif_wake_queue (and
> infact a netif_start_queue could have been used instead), instead
> call stop_queue if required, and remove code under USE_GTS macro.
> 3. There is no need to check for netif_queue_stopped, as the network
> core guarantees that for us (I am sure every driver could remove
> that check, eg e1000 - I have tested that path a few billion times
> with about a few hundred thousand qstops but the condition never
> hit even once).
>
> Thanks,
>
Hi Krishna,
Thanks for the work.
There is however a bit more cleaning to do regarding the USE_GTS macro.
I'll post a patch soon that will take your points in account.
Cheers,
Divy
^ permalink raw reply
* [PATCHv2] PHYLIB: Add BCM5482 PHY support
From: Nate Case @ 2008-01-31 0:28 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Andy Fleming, netdev
This Broadcom PHY is similar to other bcm54xx devices.
Signed-off-by: Nate Case <ncase@xes-inc.com>
---
Note: This is a re-submission, correcting the bad indentation in the first patch
drivers/net/phy/broadcom.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 29666c8..5b80358 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -141,6 +141,20 @@ static struct phy_driver bcm5461_driver = {
.driver = { .owner = THIS_MODULE },
};
+static struct phy_driver bcm5482_driver = {
+ .phy_id = 0x0143bcb0,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM5482",
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm54xx_ack_interrupt,
+ .config_intr = bcm54xx_config_intr,
+ .driver = { .owner = THIS_MODULE },
+};
+
static int __init broadcom_init(void)
{
int ret;
@@ -154,8 +168,13 @@ static int __init broadcom_init(void)
ret = phy_driver_register(&bcm5461_driver);
if (ret)
goto out_5461;
+ ret = phy_driver_register(&bcm5482_driver);
+ if (ret)
+ goto out_5482;
return ret;
+out_5482:
+ phy_driver_unregister(&bcm5461_driver);
out_5461:
phy_driver_unregister(&bcm5421_driver);
out_5421:
@@ -166,6 +185,7 @@ out_5411:
static void __exit broadcom_exit(void)
{
+ phy_driver_unregister(&bcm5482_driver);
phy_driver_unregister(&bcm5461_driver);
phy_driver_unregister(&bcm5421_driver);
phy_driver_unregister(&bcm5411_driver);
--
1.5.3.3
^ permalink raw reply related
* Re: e1000 full-duplex TCP performance well below wire speed
From: SANGTAE HA @ 2008-01-31 0:17 UTC (permalink / raw)
To: Bruce Allen; +Cc: Linux Kernel Mailing List, netdev, Stephen Hemminger
In-Reply-To: <Pine.LNX.4.63.0801301610240.19938@trinity.phys.uwm.edu>
Hi Bruce,
On Jan 30, 2008 5:25 PM, Bruce Allen <ballen@gravity.phys.uwm.edu> wrote:
>
> In our application (cluster computing) we use a very tightly coupled
> high-speed low-latency network. There is no 'wide area traffic'. So it's
> hard for me to understand why any networking components or software layers
> should take more than milliseconds to ramp up or back off in speed.
> Perhaps we should be asking for a TCP congestion avoidance algorithm which
> is designed for a data center environment where there are very few hops
> and typical packet delivery times are tens or hundreds of microseconds.
> It's very different than delivering data thousands of km across a WAN.
>
If your network latency is low, regardless of type of protocols should
give you more than 900Mbps. I can guess the RTT of two machines is
less than 4ms in your case and I remember the throughputs of all
high-speed protocols (including tcp-reno) were more than 900Mbps with
4ms RTT. So, my question which kernel version did you use with your
broadcomm NIC and got more than 900Mbps?
I have two machines connected by a gig switch and I can see what
happens in my environment. Could you post what parameters did you use
for netperf testing?
and also if you set any parameters for your testing, please post them
here so that I can see that happens to me as well.
Regards,
Sangtae
^ permalink raw reply
* Re: Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e"
From: Adrian Bunk @ 2008-01-30 23:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Randy Dunlap, Linux Kernel Mailing List, auke-jan.h.kok, jeff,
David S. Miller, akpm, netdev
In-Reply-To: <alpine.LFD.1.00.0801301631400.3426@www.l.google.com>
On Wed, Jan 30, 2008 at 04:51:04PM +1100, Linus Torvalds wrote:
>
>
> On Tue, 29 Jan 2008, Randy Dunlap wrote:
> >
> > Andrew was concerned about this when the driver was in -mm.
> > He asked for a patch that would set E1000E to same value as E1000
> > and I supplied that. Auke acked it IIRC. Other people vetoed it. :(
>
> Yeah, I've been discussing with Jeff and the gang.
>
> I think we have agreed on a solution where the ID's show up in the old
> driver if the new driver is not enabled at all.
>
> (And as a side note: it turns out that the problem I experienced didn't
> come from the new e1000e driver after all, so I'll be removing the
> EXPERIMENTAL flag again).
>
> So I'd suggest the final patch be something like this, but I'm sendign it
> out just as an example of how we could solve this, not necessarily as a
> final patch.
>
> Jeff, Auke, would something like this be acceptable? It makes it very
> obvious in the driver table which entries are for the PCIE versions that
> would be handled by the E1000E driver if it is enabled..
>
> Untested, but as mentioned, this is more of a "this looks maintainable and
> like it should solve the issues" rather than anything I was planning on
> committing now.
I don't like it:
We should aim at having exactly one driver for one card.
Your patch has effects like e.g. a kernel behaving differently when
adding and compiling the e1000e module later compared to having it
originally in the .config.
And fun like "The card works on my machine with the e1000 driver, why
doesn't it work in your machine with the e1000 driver?".
And in terms of maintainability, people will disable the e1000e driver
in their kernel for working around bugs in it instead of reporting the
bugs. Exactly what we want to not happen.
And unless we want to keep this situation forever, we anyway have to
remove the support for the PCI-Express adapters from the e1000 driver at
some point in time, so why not make a clear cut now? Whatever problems
this causes will be the same now or in a few years.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] PHYLIB: Add BCM5482 PHY support
From: Nate Case @ 2008-01-30 23:45 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Andy Fleming, netdev
In-Reply-To: <Pine.LNX.4.64N.0801300936040.20317@blysk.ds.pg.gda.pl>
On Wed, 2008-01-30 at 09:51 +0000, Maciej W. Rozycki wrote:
> > +static struct phy_driver bcm5482_driver = {
> > + .phy_id = 0x0143bcb0,
> > + .phy_id_mask = 0xfffffff0,
>
> Please check formatting above and also I am a bit curious as to why the
> ID is so different from the other ones -- the number is meant to be based
> on the OUI assigned to the manufacturer. Otherwise your addition is fine.
I'll re-submit with the formatting fixed.
I can't figure out why the ID is so different from the others, but I did
double-check it and test it on real hardware.
For what it's worth, I've found a lot of inconsistency in these ID
values. For example, the chips with ID1 == 0x0020 seem to use the wrong
set of OUI bits (22:7 instead of 21:6), while others (BCM5221) with ID1
== 0x0040 do it properly conforming to the IEEE standard.
I can't figure out how they got the ID values for the BCM5482. If you
extract the OUI from 0x0143bcb0, you get 0x0050ef (which the *BSD guys
list as an alternate "mangled" Broadcom OUI). The BCM5787 and BCM5755
also seem to share this same ID formula with the BCM5482.
- Nate Case <ncase@xes-inc.com>
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 23:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <20080130143335.7fc9ea21@deepthought>
Hi Stephen,
>>>> Indeed, we are not asking to see 1000 Mb/s. We'd be happy to see 900
>>>> Mb/s.
>>>>
>>>> Netperf is trasmitting a large buffer in MTU-sized packets (min 1500
>>>> bytes). Since the acks are only about 60 bytes in size, they should be
>>>> around 4% of the total traffic. Hence we would not expect to see more
>>>> than 960 Mb/s.
>>
>>> Don't forget the network overhead: http://sd.wareonearth.com/~phil/net/overhead/
>>> Max TCP Payload data rates over ethernet:
>>> (1500-40)/(38+1500) = 94.9285 % IPv4, minimal headers
>>> (1500-52)/(38+1500) = 94.1482 % IPv4, TCP timestamps
>>
>> Yes. If you look further down the page, you will see that with jumbo
>> frames (which we have also tried) on Gb/s ethernet the maximum throughput
>> is:
>>
>> (9000-20-20-12)/(9000+14+4+7+1+12)*1000000000/1000000 = 990.042 Mbps
>>
>> We are very far from this number -- averaging perhaps 600 or 700 Mbps.
> That is the upper bound of performance on a standard PCI bus (32 bit).
> To go higher you need PCI-X or PCI-Express. Also make sure you are really
> getting 64-bit PCI, because I have seen some e1000 PCI-X boards that
> are only 32bit.
The motherboard NIC is in a PCI-e x1 slot. This has a maximum speed of
250 MB/s (2 Gb/s) in each direction. It should be a factor of 2 more
interface speed than is needed.
Cheers,
Bruce
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Benjamin Herrenschmidt @ 2008-01-30 23:14 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Josh Boyer, netdev
In-Reply-To: <200801300716.52463.sr@denx.de>
On Wed, 2008-01-30 at 07:16 +0100, Stefan Roese wrote:
> On Wednesday 16 January 2008, Josh Boyer wrote:
> > On Wed, 16 Jan 2008 20:53:59 +1100
> >
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> > > > With the removal the the "rgmii-interface" device_type property from
> > > > the dts files, the newemac driver needs an update to only rely on
> > > > compatible property.
> > > >
> > > > Signed-off-by: Stefan Roese <sr@denx.de>
> > >
> > > I need to test if it works on CAB, can't change the DT on those. I'll
> > > let you know tomorrow.
> >
> > This should be fine on CAB. The rgmii node has:
> >
> > compatible = "ibm,rgmii-axon", "ibm,rgmii"
> >
> > so the match should still catch on the latter.
>
> How about this patch? Ben, if you think this is ok then we should make sure
> that it goes in in this merge-window, since the other dts patch relies on it.
It's fine.
Ben.
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 23:15 UTC (permalink / raw)
To: Rick Jones
Cc: Brandeburg, Jesse, netdev, Carsten Aulbert, Henning Fehrmann,
Bruce Allen
In-Reply-To: <47A0C5B2.1000500@hp.com>
Hi Rick,
First off, thanks for netperf. I've used it a lot and find it an extremely
useful tool.
>> As asked in LKML thread, please post the exact netperf command used to
>> start the client/server, whether or not you're using irqbalanced (aka
>> irqbalance) and what cat /proc/interrupts looks like (you ARE using MSI,
>> right?)
>
> In particular, it would be good to know if you are doing two concurrent
> streams, or if you are using the "burst mode" TCP_RR with large
> request/response sizes method which then is only using one connection.
I'm not sure -- must wait for Henning and Carsten to respond tomorrow.
Cheers,
Bruce
^ permalink raw reply
* RE: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 23:07 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: netdev, Carsten Aulbert, Henning Fehrmann, Bruce Allen
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F52044F81DF@orsmsx418.amr.corp.intel.com>
Hi Jesse,
It's good to be talking directly to one of the e1000 developers and
maintainers. Although at this point I am starting to think that the
issue may be TCP stack related and nothing to do with the NIC. Am I
correct that these are quite distinct parts of the kernel?
> The 82573L (a client NIC, regardless of the class of machine it is in)
> only has a x1 connection which does introduce some latency since the
> slot is only capable of about 2Gb/s data total, which includes overhead
> of descriptors and other transactions. As you approach the maximum of
> the slot it gets more and more difficult to get wire speed in a
> bidirectional test.
According to the Intel datasheet, the PCI-e x1 connection is 2Gb/s in each
direction. So we only need to get up to 50% of peak to saturate a
full-duplex wire-speed link. I hope that the overhead is not a factor of
two.
Important note: we ARE able to get full duplex wire speed (over 900 Mb/s
simulaneously in both directions) using UDP. The problems occur only with
TCP connections.
>> The test was done with various mtu sizes ranging from 1500 to 9000,
>> with ethernet flow control switched on and off, and using reno and
>> cubic as a TCP congestion control.
>
> As asked in LKML thread, please post the exact netperf command used to
> start the client/server, whether or not you're using irqbalanced (aka
> irqbalance) and what cat /proc/interrupts looks like (you ARE using MSI,
> right?)
I have to wait until Carsten or Henning wake up tomorrow (now 23:38 in
Germany). So we'll provide this info in ~10 hours.
I assume that the interrupt load is distributed among all four cores --
the default affinity is 0xff, and I also assume that there is some type of
interrupt aggregation taking place in the driver. If the CPUs were not
able to service the interrupts fast enough, I assume that we would also
see loss of performance with UDP testing.
> I've recently discovered that particularly with the most recent kernels
> if you specify any socket options (-- -SX -sY) to netperf it does worse
> than if it just lets the kernel auto-tune.
I am pretty sure that no socket options were specified, but again need to
wait until Carsten or Henning come back on-line.
>> The behavior depends on the setup. In one test we used cubic
>> congestion control, flow control off. The transfer rate in one
>> direction was above 0.9Gb/s while in the other direction it was 0.6
>> to 0.8 Gb/s. After 15-20s the rates flipped. Perhaps the two steams
>> are fighting for resources. (The performance of a full duplex stream
>> should be close to 1Gb/s in both directions.) A graph of the
>> transfer speed as a function of time is here:
>> https://n0.aei.uni-hannover.de/networktest/node19-new20-noflow.jpg
>> Red shows transmit and green shows receive (please ignore other
>> plots):
> One other thing you can try with e1000 is disabling the dynamic
> interrupt moderation by loading the driver with
> InterruptThrottleRate=8000,8000,... (the number of commas depends on
> your number of ports) which might help in your particular benchmark.
OK. Is 'dynamic interrupt moderation' another name for 'interrupt
aggregation'? Meaning that if more than one interrupt is generated in a
given time interval, then they are replaced by a single interrupt?
> just for completeness can you post the dump of ethtool -e eth0 and lspci
> -vvv?
Yup, we'll give that info also.
Thanks again!
Cheers,
Bruce
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Francois Romieu @ 2008-01-30 22:47 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Jeff Garzik, David Miller, netdev, LKML
In-Reply-To: <20080130102116.GA20846@uranus.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> :
[...]
> > -static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
> > +static struct pci_device_id sis190_pci_tbl[] = {
> > { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
> > { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
> > { 0, },
>
> The __devinitdata is OK, it is the following _devinitdata that had
> to be _devinitconst.
Strangely enough, removing the devinitdata from the sis190_pci_tbl
silents the error message here. Do you have an explanation ?
--
Ueimor
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Stephen Hemminger @ 2008-01-30 22:33 UTC (permalink / raw)
To: Bruce Allen; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <Pine.LNX.4.63.0801301610240.19938@trinity.phys.uwm.edu>
On Wed, 30 Jan 2008 16:25:12 -0600 (CST)
Bruce Allen <ballen@gravity.phys.uwm.edu> wrote:
> Hi Stephen,
>
> Thanks for your helpful reply and especially for the literature pointers.
>
> >> Indeed, we are not asking to see 1000 Mb/s. We'd be happy to see 900
> >> Mb/s.
> >>
> >> Netperf is trasmitting a large buffer in MTU-sized packets (min 1500
> >> bytes). Since the acks are only about 60 bytes in size, they should be
> >> around 4% of the total traffic. Hence we would not expect to see more
> >> than 960 Mb/s.
>
> > Don't forget the network overhead: http://sd.wareonearth.com/~phil/net/overhead/
> > Max TCP Payload data rates over ethernet:
> > (1500-40)/(38+1500) = 94.9285 % IPv4, minimal headers
> > (1500-52)/(38+1500) = 94.1482 % IPv4, TCP timestamps
>
> Yes. If you look further down the page, you will see that with jumbo
> frames (which we have also tried) on Gb/s ethernet the maximum throughput
> is:
>
> (9000-20-20-12)/(9000+14+4+7+1+12)*1000000000/1000000 = 990.042 Mbps
>
> We are very far from this number -- averaging perhaps 600 or 700 Mbps.
>
That is the upper bound of performance on a standard PCI bus (32 bit).
To go higher you need PCI-X or PCI-Express. Also make sure you are really
getting 64-bit PCI, because I have seen some e1000 PCI-X boards that
are only 32bit.
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 22:33 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, Carsten Aulbert, Henning Fehrmann, Bruce Allen
In-Reply-To: <47A0CD3B.3050502@candelatech.com>
Hi Ben,
Thank you for the suggestions and questions.
>> We've connected a pair of modern high-performance boxes with integrated
>> copper Gb/s Intel NICS, with an ethernet crossover cable, and have run some
>> netperf full duplex TCP tests. The transfer rates are well below wire
>> speed. We're reporting this as a kernel bug, because we expect a vanilla
>> kernel with default settings to give wire speed (or close to wire speed)
>> performance in this case. We DO see wire speed in simplex transfers. The
>> behavior has been verified on multiple machines with identical hardware.
>
> Try using NICs in the pci-e slots. We have better luck there, as you
> usually have more lanes and/or higher quality NIC chipsets available in
> this case.
It's a good idea. We can try this, though it will take a little time to
organize.
> Try a UDP test to make sure the NIC can actually handle the throughput.
I should have mentioned this in my original post -- we already did this.
We can run UDP wire speed full duplex (over 900 Mb/s in each direction, at
the same time). So the problem stems from TCP or is aggravated by TCP.
It's not a hardware limitation.
> Look at the actual link usage as reported by the ethernet driver so that
> you take all of the ACKS and other overhead into account.
OK. We'll report on this as soon as possible.
> Try the same test using 10G hardware (CX4 NICs are quite affordable
> these days, and we drove a 2-port 10G NIC based on the Intel ixgbe
> chipset at around 4Gbps on two ports, full duplex, using pktgen). As in
> around 16Gbps throughput across the busses. That may also give you an
> idea if the bottleneck is hardware or software related.
OK. That will take more time to organize.
Cheers,
Bruce
>
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 22:25 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev, Stephen Hemminger
In-Reply-To: <20080130082136.1017631d@deepthought>
Hi Stephen,
Thanks for your helpful reply and especially for the literature pointers.
>> Indeed, we are not asking to see 1000 Mb/s. We'd be happy to see 900
>> Mb/s.
>>
>> Netperf is trasmitting a large buffer in MTU-sized packets (min 1500
>> bytes). Since the acks are only about 60 bytes in size, they should be
>> around 4% of the total traffic. Hence we would not expect to see more
>> than 960 Mb/s.
> Don't forget the network overhead: http://sd.wareonearth.com/~phil/net/overhead/
> Max TCP Payload data rates over ethernet:
> (1500-40)/(38+1500) = 94.9285 % IPv4, minimal headers
> (1500-52)/(38+1500) = 94.1482 % IPv4, TCP timestamps
Yes. If you look further down the page, you will see that with jumbo
frames (which we have also tried) on Gb/s ethernet the maximum throughput
is:
(9000-20-20-12)/(9000+14+4+7+1+12)*1000000000/1000000 = 990.042 Mbps
We are very far from this number -- averaging perhaps 600 or 700 Mbps.
> I believe what you are seeing is an effect that occurs when using
> cubic on links with no other idle traffic. With two flows at high speed,
> the first flow consumes most of the router buffer and backs off gradually,
> and the second flow is not very aggressive. It has been discussed
> back and forth between TCP researchers with no agreement, one side
> says that it is unfairness and the other side says it is not a problem in
> the real world because of the presence of background traffic.
At least in principle, we should have NO congestion here. We have ports
on two different machines wired with a crossover cable. Box A can not
transmit faster than 1 Gb/s. Box B should be able to receive that data
without dropping packets. It's not doing anything else!
> See:
> http://www.hamilton.ie/net/pfldnet2007_cubic_final.pdf
> http://www.csc.ncsu.edu/faculty/rhee/Rebuttal-LSM-new.pdf
This is extremely helpful. The typical oscillation (startup) period shown
in the plots in these papers is of order 10 seconds, which is similar to
the types of oscillation periods that we are seeing.
*However* we have also seen similar behavior with the Reno congestion
control algorithm. So this might not be due to cubic, or entirely due to
cubic.
In our application (cluster computing) we use a very tightly coupled
high-speed low-latency network. There is no 'wide area traffic'. So it's
hard for me to understand why any networking components or software layers
should take more than milliseconds to ramp up or back off in speed.
Perhaps we should be asking for a TCP congestion avoidance algorithm which
is designed for a data center environment where there are very few hops
and typical packet delivery times are tens or hundreds of microseconds.
It's very different than delivering data thousands of km across a WAN.
Cheers,
Bruce
^ permalink raw reply
* Re: [2.6 patch] make e1000_dump_eeprom() static
From: Kok, Auke @ 2008-01-30 21:52 UTC (permalink / raw)
To: Adrian Bunk
Cc: Jeff Garzik, e1000-devel, netdev, jesse.brandeburg, linux-kernel,
john.ronciak, jeffrey.t.kirsher
In-Reply-To: <20080130200245.GZ29368@does.not.exist>
Adrian Bunk wrote:
> This patch makes the needlessly global e1000_dump_eeprom() static.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
yes, thanks, I'll push it to Jeff.
Auke
>
> ---
> b5fd924a1388d4aaa94cf05e42e317c2b1fb5748
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> index 7f5b2ae..8a6645b 100644
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -820,7 +820,7 @@ e1000_reset(struct e1000_adapter *adapter)
> /**
> * Dump the eeprom for users having checksum issues
> **/
> -void e1000_dump_eeprom(struct e1000_adapter *adapter)
> +static void e1000_dump_eeprom(struct e1000_adapter *adapter)
> {
> struct net_device *netdev = adapter->netdev;
> struct ethtool_eeprom eeprom;
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [2.6 patch] e1000e/ethtool.c: make a function static
From: Kok, Auke @ 2008-01-30 21:51 UTC (permalink / raw)
To: Adrian Bunk
Cc: Jeff Garzik, e1000-devel, netdev, jesse.brandeburg, linux-kernel,
john.ronciak, jeffrey.t.kirsher, Joe Perches
In-Reply-To: <20080130200243.GY29368@does.not.exist>
Adrian Bunk wrote:
> This patch makes the needlessly global reg_pattern_test_array() static.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
stephen hemminger already pointed this out to me... I'll certainly push this
upstream, thanks Adrian!
Auke
>
> ---
> ed72e457f06311390d9a9e51a00c904939466aff
> diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
> index 6d9c27f..a2034cf 100644
> --- a/drivers/net/e1000e/ethtool.c
> +++ b/drivers/net/e1000e/ethtool.c
> @@ -690,8 +690,8 @@ err_setup:
> return err;
> }
>
> -bool reg_pattern_test_array(struct e1000_adapter *adapter, u64 *data,
> - int reg, int offset, u32 mask, u32 write)
> +static bool reg_pattern_test_array(struct e1000_adapter *adapter, u64 *data,
> + int reg, int offset, u32 mask, u32 write)
> {
> int i;
> u32 read;
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [PATCH] Add another Prism2 card to hostap
From: Pavel Roskin @ 2008-01-30 21:15 UTC (permalink / raw)
To: Marcin Juszkiewicz
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jouni Malinen,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200801290942.56258.openembedded-sbG99h22wavzs492ZWNkEA@public.gmane.org>
On Tue, 2008-01-29 at 09:42 +0100, Marcin Juszkiewicz wrote:
> From: Marcin Juszkiewicz <openembedded-sbG99h22wavzs492ZWNkEA@public.gmane.org>
>
> Card reported by Ångström user:
> http://bugs.openembedded.net/show_bug.cgi?id=3236
>
> Socket 1:
> product info: "Wireless LAN", "11Mbps PC Card", "Version 01.02", ""
> manfid: 0x0156, 0x0002
> function: 6 (network)
>
> Signed-off-by: Marcin Juszkiewicz <openembedded-sbG99h22wavzs492ZWNkEA@public.gmane.org>
Acked-by: Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org>
> diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c
> index 877d3bd..4f6707c 100644
> --- a/drivers/net/wireless/hostap/hostap_cs.c
> +++ b/drivers/net/wireless/hostap/hostap_cs.c
> @@ -894,6 +894,9 @@ static struct pcmcia_device_id hostap_cs_ids[] = {
> "The Linksys Group, Inc.", "Wireless Network CF Card", "ISL37300P",
> "RevA",
> 0xa5f472c2, 0x9c05598d, 0xc9049a39, 0x57a66194),
> + PCMCIA_DEVICE_PROD_ID123(
> + "Wireless LAN" , "11Mbps PC Card", "Version 01.02",
> + 0x4b8870ff, 0x70e946d1, 0x4b74baa0),
> PCMCIA_DEVICE_NULL
> };
> MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
>
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [2.6 patch] unexport sysctl_tcp_tso_win_divisor
From: Ilpo Järvinen @ 2008-01-30 21:05 UTC (permalink / raw)
To: Adrian Bunk; +Cc: David S. Miller, Netdev
In-Reply-To: <20080130200232.GU29368@does.not.exist>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 763 bytes --]
On Wed, 30 Jan 2008, Adrian Bunk wrote:
> This patch removes the no longer used
> EXPORT_SYMBOL(sysctl_tcp_tso_win_divisor).
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
> 4884e7997ba5f63f2efeaeead21ed2768fb3f4de
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 89f0188..ed750f9 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2564,5 +2564,4 @@ EXPORT_SYMBOL(tcp_connect);
> EXPORT_SYMBOL(tcp_make_synack);
> EXPORT_SYMBOL(tcp_simple_retransmit);
> EXPORT_SYMBOL(tcp_sync_mss);
> -EXPORT_SYMBOL(sysctl_tcp_tso_win_divisor);
> EXPORT_SYMBOL(tcp_mtup_init);
...yes, results from the recent move of tcp_is_cwnd_limited() away from
tcp.h.
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
--
i.
^ permalink raw reply
* Re: [PATCH net-2.6.25 4/7][ATM]: [br2864] routed support
From: chas williams - CONTRACTOR @ 2008-01-30 20:49 UTC (permalink / raw)
To: Chung-Chi Lo; +Cc: netdev, davem
In-Reply-To: <3f696b20801282342q43537963ueb8fb9cf3389ac03@mail.gmail.com>
In message <3f696b20801282342q43537963ueb8fb9cf3389ac03@mail.gmail.com>,"Chung-
Chi Lo" writes:
>> + } else { /* vc-mux */
>> + if (brdev->payload == p_routed) {
>
>add line
>
> skb->protocol = __constant_htons(ETH_P_IP);
>
>here just like LLC did?
>
>> + skb_reset_network_header(skb);
>> + skb->pkt_type = PACKET_HOST;
yes, that is missing but it needs to be a little more complicated than
that i think. you need to examine the first byte to see if its an
ipv4 or ipv6 datagram. something like:
struct iphdr *iph = skb_network_header(skb);
skb_reset_network_header(skb);
iph = skb_network_header(skb);
if (iph->version == 4)
skb->protocol = __constant_htons(ETH_P_IP);
else if (iph->version == 6)
skb->protocol = __constant_htons(ETH_P_IPV6);
else
/* drop the packet */
skb->pkt_type = PACKET_HOST;
how does that look?
>+ } else {
>+ skb_push(skb, 2);
>+ if (brdev->payload == p_bridged)
>+ memset(skb->data, 0, 2);
>+ }
>
>Here should be
>
> } else {
> if (brdev->payload == p_bridged) {
> skb_push(skb, 2);
> memset(skb->data, 0, 2);
> }
> }
>
>Because VCMUX and routed mode doesn't need two bytes in header.
yeah, another oversight. your fix is correct. i bet you have guessed
that we dont use vc multiplexing.
^ permalink raw reply
* Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
From: Ondrej Zary @ 2008-01-30 20:23 UTC (permalink / raw)
To: jgarzik; +Cc: Linux Kernel, netdev
In-Reply-To: <200801262158.12016.linux@rainbow-software.org>
On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
> Hello,
> I was having problems with these FreedomLine cards with Linux before but
> tested it thoroughly today. This card uses DEC 21041 chip and has TP and
> BNC connectors:
>
> 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip
> 21041 [Tulip Pass 3] [1011:0014] (rev 21)
>
>
> de2104x driver was loaded automatically by udev and card seemed to work.
> Until I disconnected the TP cable and putting it back after a while. The
> driver then switched to (non-existing) AUI port and remained there. I tried
> to set media to TP using ethtool - and the whole kernel crashed because of
> BUG_ON(de_is_running(de));
> in de_set_media(). Seems that the driver is unable to stop the DMA in
> de_stop_rxtx().
>
> I commented out AUI detection in the driver - this time it switched to BNC
> after unplugging the cable and remained there. I also attempted to reset
> the chip when de_stop_rxtx failed but failed to do it.
>
> Then I found that there's de4x5 driver which supports the same cards as
> de2104x (and some other too) - and this one works fine! I can plug and
> unplug the cable and even change between TP and BNC ports just by
> unplugging one and plugging the other cable in. Unfortunately, this driver
> is blacklisted by default - at least in Slackware and Debian.
>
> The question is: why does de2104x exist? Does it work better with some
> hardware?
>
> BTW. Found that the problem exist at least since 2003:
> http://oss.sgi.com/archives/netdev/2003-08/msg00951.html
Does the de2104x driver work correctly for anyone?
--
Ondrej Zary
^ permalink raw reply
* rtl8150: use default MTU of 1500
From: Lennert Buytenhek @ 2008-01-30 19:37 UTC (permalink / raw)
To: netdev, jgarzik; +Cc: Petko Manolov
The RTL8150 driver uses an MTU of 1540 by default, which causes a
bunch of problems -- it prevents booting from NFS root, for one.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Petko Manolov <petkan@nucleusys.com>
--- linux-2.6.24-git7.orig/drivers/net/usb/rtl8150.c 2008-01-24 23:58:37.000000000 +0100
+++ linux-2.6.24-git7/drivers/net/usb/rtl8150.c 2008-01-30 20:29:00.000000000 +0100
@@ -925,9 +925,8 @@
netdev->hard_start_xmit = rtl8150_start_xmit;
netdev->set_multicast_list = rtl8150_set_multicast;
netdev->set_mac_address = rtl8150_set_mac_address;
netdev->get_stats = rtl8150_netdev_stats;
- netdev->mtu = RTL8150_MTU;
SET_ETHTOOL_OPS(netdev, &ops);
dev->intr_interval = 100; /* 100ms */
if (!alloc_all_urbs(dev)) {
^ permalink raw reply
* Re: [2.6 patch] rtnetlink.c: #if 0 no longer used functions
From: Patrick McHardy @ 2008-01-30 20:04 UTC (permalink / raw)
To: Adrian Bunk; +Cc: David S. Miller, netdev
In-Reply-To: <20080130200257.GD29368@does.not.exist>
Adrian Bunk wrote:
> This patch #if 0's the following no longer used functions:
> - rtattr_parse()
> - rtattr_strlcpy()
> - __rtattr_parse_nested_compat()
>
Please remove them instead.
^ 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