Hi Bill,
I started musing if once one side's transmitter got the upper hand, it
might somehow defer the processing of received packets, causing the
resultant ACKs to be delayed and thus further slowing down the other
end's transmitter. I began to wonder if the txqueuelen could have an
affect
Hi.
On Fri, Feb 01, 2008 at 02:04:39AM +0100, Jan Engelhardt ([EMAIL PROTECTED])
wrote:
> >POHMELFS stands for Parallel Optimized Host Message Exchange
> >Layered File System. It allows to mount remote servers to local
> >directory via network. This filesystem supports local caching
> >and writeb
On 01-02-2008 00:04, Jarek Poplawski wrote:
...
> ...On the other hand, with this DSL argument from the sub-thread you
> could be quite right: if this "everyone" wants to use one NIC for
> both high speed local network and such a DSL, then learning ethtool
> could be not enough...
...But, on the o
Andi Kleen wrote:
The problem with ethtool is that it's a non-obvious nerd knob. At
the least the ethtool documentation should be updated to indicate that
activating TSO effects tc accuracy.
TSO tends to be activated by default in the driver; very few people who use it
do even know that ethto
> The problem with ethtool is that it's a non-obvious nerd knob. At
> the least the ethtool documentation should be updated to indicate that
> activating TSO effects tc accuracy.
TSO tends to be activated by default in the driver; very few people who use it
do even know that ethtool exist or wha
David Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 30 Jan 2008 21:04:33 +0100
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.
Agreed.
The
Glen Turner wrote:
On Thu, 2008-01-31 at 20:34 +0100, Andi Kleen wrote:
The philosophical problem I have with this suggestion is that I expect
that the large majority of users will be more happy with disabled TSO
if they use non standard qdiscs and defaults that do not fit
the majority use cas
if_addrlabel.h is needed for iproute2 usage.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
include/linux/Kbuild |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 85b2482..ce9d0fd 100644
--- a/include/linux/Kbuild
On Thu, 2008-01-31 at 20:34 +0100, Andi Kleen wrote:
> The philosophical problem I have with this suggestion is that I expect
> that the large majority of users will be more happy with disabled TSO
> if they use non standard qdiscs and defaults that do not fit
> the majority use case are bad.
I
applied both to git
--
Stephen Hemminger <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 31 Jan 2008, Bruce Allen wrote:
> >> Based on the discussion in this thread, I am inclined to believe that
> >> lack of PCI-e bus bandwidth is NOT the issue. The theory is that the
> >> extra packet handling associated with TCP acknowledgements are pushing
> >> the PCI-e x1 bus past its l
On Fri, 01 Feb 2008 06:34:34 +0100
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > Provide a way to use tc filters on vlan tag even if tag is buried in
> > skb due to hardware acceleration.
>
> Looks reasonable. Would you like to add the same feature to the
> flow classi
Stephen Hemminger wrote:
Provide a way to use tc filters on vlan tag even if tag is buried in
skb due to hardware acceleration.
Looks reasonable. Would you like to add the same feature to the
flow classifier?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
Provide a way to use tc filters on vlan tag even if tag is buried in
skb due to hardware acceleration.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
include/linux/pkt_cls.h |3 ++-
include/linux/tc_ematch/tc_em_meta.h |1 +
net/sched/em_meta.c |
On Thu, 31 Jan 2008 21:05:42 CST, Nathan Lynch wrote:
> Doug Maxey wrote:
> >
> > A small set of fixups for checkpatch.
> >
> > Based on upstream pull from a few hours ago.
>
> Er, ehea doesn't even build right now[1], maybe that could get fixed
> first? :-)
>
> [1] http://lkml.org/lkml/2008/
Waskiewicz Jr, Peter P wrote:
Well, it could be just that when using such qdiscs TSO would be
disabled, but the user could override this by using ethtool after
loading the qdiscs.
I still disagree with this. The qdisc should not cause anything to happen to
feature flags on the device. It's th
On Thu, Jan 31, 2008 at 09:33:44PM +0100, Jarek Poplawski wrote:
> Andi Kleen wrote, On 01/31/2008 08:34 PM:
>
> >> TSO by nature is bursty. But disabling TSO without the option of having
> >> it on or off to me seems to aggressive. If someone is using a qdisc
> >> that TSO is interfering with t
> Well, it could be just that when using such qdiscs TSO would be
> disabled, but the user could override this by using ethtool after
> loading the qdiscs.
If anything TC, not ethtool. Do you have an useful scenario where
GSO makes sense with TBF et.al.?
-Andi
--
To unsubscribe from this list: se
On Thu, Jan 31, 2008 at 03:42:54PM -0800, Waskiewicz Jr, Peter P wrote:
> > Well, it could be just that when using such qdiscs TSO would be
> > disabled, but the user could override this by using ethtool after
> > loading the qdiscs.
>
> I still disagree with this. The qdisc should not cause anyt
On Thu, Jan 31, 2008 at 11:14:34AM -0800, Rick Jones wrote:
> Sounds like the functionality needs to be in the DSL bridge :) (or the
> "router" in the same case) Particularly since it might be getting used
> by more than one host on the GbE switch.
Possible, but it is not usually in the real wor
I've just sent a pull request to Linus for net-2.6 and that should
effectively be my final feature merge to him.
Outside of the 6-patch thing Arnaldo is respinning I am calling for no
new stuff to go in at this time. Only bug fixes.
We've merged a lot of stuff already (on the order of 1800 patc
Doug Maxey wrote:
>
> A small set of fixups for checkpatch.
>
> Based on upstream pull from a few hours ago.
Er, ehea doesn't even build right now[1], maybe that could get fixed
first? :-)
[1] http://lkml.org/lkml/2008/1/28/337
--
To unsubscribe from this list: send the line "unsubscribe netde
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]>
Signed-off-by: Doug Maxey <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c | 87 ++
1 files changed, 46 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
i
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]>
Signed-off-by: Doug Maxey <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_phyp.c | 158 +-
drivers/net/ehea/ehea_phyp.h | 22 +++---
2 files changed, 90 insertions(+), 90 deletions(-)
diff --git a/drivers/net/ehea/
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]>
Signed-off-by: Doug Maxey <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_qmr.c | 32
drivers/net/ehea/ehea_qmr.h | 16
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ehea/eh
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]>
Signed-off-by: Doug Maxey <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_ethtool.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ehea/ehea_ethtool.c b/drivers/net/ehea/ehea_ethtool.c
index 679f40e..d768852 100644
--
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]>
Signed-off-by: Doug Maxey <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h|3 +++
drivers/net/ehea/ehea_hw.h |8
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 5f82
A small set of fixups for checkpatch.
Based on upstream pull from a few hours ago.
drivers/net/ehea/ehea.h |3 +
drivers/net/ehea/ehea_ethtool.c |4 +-
drivers/net/ehea/ehea_hw.h |8 +-
drivers/net/ehea/ehea_main.c| 87 +++--
drivers/net/ehea/ehea_
On Feb 1, 2008 10:33 AM, David Miller <[EMAIL PROTECTED]> wrote:
> From: Dave Young <[EMAIL PROTECTED]>
> Date: Fri, 1 Feb 2008 09:24:41 +0800
>
>
> > On Thu, Jan 31, 2008 at 02:09:30PM +0100, Jens Axboe wrote:
> > > On Wed, Jan 30 2008, Dave Young wrote:
> > > >
> > > > The bluetooth hci_conn sysf
From: "Denis V. Lunev" <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 14:59:49 +0300
> Here are some preparations and cleanups to enable network device/inet
> address notifiers inside a namespace.
>
> This set of patches has been originally sent last Friday. One cleanup
> patch from the original seri
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 16:31:38 -0200
> Hi David,
>
> Please consider pulling from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6
I've had to rebase my tree a few times and there are
conflicts in this merge as well.
Sit ti
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 18:58:02 +0100 (MET)
> These patches add support for external classifiers to SFQ and add a
> new "flow" classifier, which can do hashing based on user-specified
> keys or deterministic mapping of keys to classes. Additionally there
>
From: Dave Young <[EMAIL PROTECTED]>
Date: Fri, 1 Feb 2008 09:24:41 +0800
> On Thu, Jan 31, 2008 at 02:09:30PM +0100, Jens Axboe wrote:
> > On Wed, Jan 30 2008, Dave Young wrote:
> > >
> > > The bluetooth hci_conn sysfs add/del executed in the default workqueue.
> > > If the del_conn is executed
On Thu, Jan 31, 2008 at 02:09:30PM +0100, Jens Axboe wrote:
> On Wed, Jan 30 2008, Dave Young wrote:
> >
> > 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 "sa
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 30 Jan 2008 21:04:33 +0100
> 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.
Agreed.
--
T
From: Masahide NAKAMURA <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 16:49:52 +0900
> [PATCH][XFRM]: Fix statistics.
>
> o Outbound sequence number overflow error status
> is counted as XfrmOutStateSeqError.
> o Additionaly, it changes inbound sequence number replay
> error name from XfrmInSeqO
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Wed, 30 Jan 2008 22:02:21 +0200
> This patch removes the following no longer used EXPORT_SYMBOL's:
> - xfrm_input.c: xfrm_parse_spi
> - xfrm_state.c: xfrm_replay_check
> - xfrm_state.c: xfrm_replay_advance
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTE
Rick Jones wrote:
then the qdisc could/should place a cap on the size of a 'TSO' based on
the bitrate (and perhaps input as to how much time any one "burst" of
data should be allowed to consume on the network) and pass that up the
stack? right now you seem to be proposing what is effectively
From: Roel Kluin <[EMAIL PROTECTED]>
Date: Wed, 30 Jan 2008 15:36:44 +0100
> Untested patch below, please confirm it's the right fix (should it be some
> other IFF_*?)
> --
> duplicate IFF_BROADCAST, remove 2nd
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
Applied, thanks.
--
To unsubscribe
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Wed, 30 Jan 2008 10:51:10 -0800
> [BNX2]: Fix ASYM PAUSE advertisement for remote PHY.
>
> We were checking for the ASYM_PAUSE bit for 1000Base-X twice instead
> checking for both the 1000Base-X bit and the 10/100/1000Base-T bit.
> The purpose of the
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 30 Jan 2008 09:08:56 +0100
> Current ip route cache implementation is not suited to large caches.
>
> We can consume a lot of CPU when cache must be invalidated, since we
> currently need to evict all cache entries, and this eviction is
> sometime
On Jan 31 2008 22:17, Evgeniy Polyakov wrote:
>
>POHMELFS stands for Parallel Optimized Host Message Exchange
>Layered File System. It allows to mount remote servers to local
>directory via network. This filesystem supports local caching
>and writeback flushing.
>POHMELFS is a brick in a future di
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Date: Mon, 28 Jan 2008 13:16:35 -0800
> when using pktgen to send delay packets the module prints repeatedly to the
> kernel log:
> sleeping for X
> sleeping for X
> ...
>
> This is probably just a debugging item left in and should not be enabled for
> r
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 29 Jan 2008 16:28:11 +0100
> [NET_SCHED]: sch_ingress: remove netfilter support
>
> Since the old policer code is gone, TC actions are needed for policing.
> The ingress qdisc can get packets directly from netif_receive_skb()
>
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 29 Jan 2008 16:19:04 +0100
> Rami Rosen wrote:
> > Hi,
> > In drivers/net/macvlan.c, when rtnl_link_register() fails
> > in macvlan_init_module(), there is no point to set it (second time in this
> > method) to macvlan_handle_frame; macvlan_in
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: shanwei <[EMAIL PROTECTED]>
Date: Mon, 28 Jan 2008 10:05:35 +0800
> Stephen Hemminger 写道:
> > On Fri, 25 Jan 2008 15:10:13 +0800
> > shanwei <[EMAIL PROTECTED]> wrote:
> >
> >> hi all:
> >>
> >> In strategy_allowed_congestion_control of the 2.6.24 kernel,
> >> when sysctl_string return 1 o
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 24 Jan 2008 13:51:12 -0800
> Normally during a dump the key of the last dumped entry is used for
> continuation, but since lock is dropped it might be lost. In that case
> fallback to the old counter based N^2 behaviour. This means the dump w
From: "Rami Rosen" <[EMAIL PROTECTED]>
Date: Wed, 23 Jan 2008 16:38:09 +0200
> Hi,
> - Remove an unused definition (LAT_BUCKETS_MAX) in net/core/pktgen.c.
> - Remove the corresponding comment.
> - The LAT_BUCKETS_MAX seems to have to do with a patch from a long
> time ago which was not applied (Be
From: Jim Paris <[EMAIL PROTECTED]>
Date: Mon, 21 Jan 2008 17:02:48 -0500
> This is needed because in ndisc.c, we have:
>
> static void ndisc_router_discovery(struct sk_buff *skb)
> {
> // ...
> if (ndopts.nd_opts_mtu) {
> // ...
> if (rt)
>
Andy Gospodarek wrote:
> (Reposted with the version I intended -- added ',' so it compiles!)
>
> There's too much noise on systems that don't support MSI. Let's get rid
> of a few and make the real error message more specific.
>
> Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]>
thanks Andy,
> Well, it could be just that when using such qdiscs TSO would be
> disabled, but the user could override this by using ethtool after
> loading the qdiscs.
I still disagree with this. The qdisc should not cause anything to happen to
feature flags on the device. It's the scheduling layer and real
Em Thu, Jan 31, 2008 at 11:39:55AM -0800, Waskiewicz Jr, Peter P escreveu:
> > The philosophical problem I have with this suggestion is that
> > I expect that the large majority of users will be more happy
> > with disabled TSO if they use non standard qdiscs and
> > defaults that do not fit the
On Thu, Jan 31, 2008 at 05:56:39PM -0500, Andy Gospodarek wrote:
>
> There's too much noise on systems that don't support MSI. Let's get rid
> of the unneeded message and make the real error message more specific.
>
> Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]>
> ---
>
> netdev.c | 12
Jarek Poplawski wrote, On 01/31/2008 09:33 PM:
> Andi Kleen wrote, On 01/31/2008 08:34 PM
...
>> Basically you're suggesting that nearly everyone using tc should learn about
>> another obscure command
...On the other hand, with this DSL argument from the sub-thread you
could be quite right:
There's too much noise on systems that don't support MSI. Let's get rid
of the unneeded message and make the real error message more specific.
Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]>
---
netdev.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/dri
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>In bond_main.c:
>
>int bond_create(char *name, struct bond_params *params, struct bonding
>**newbond)
>{
>...
>/* Check to see if the bond already exists. */
>list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list)
>i
In bond_main.c:
int bond_create(char *name, struct bond_params *params, struct bonding
**newbond)
{
...
/* Check to see if the bond already exists. */
list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list)
if (strnicmp(bond->dev->name, name, IFNAMSIZ) == 0)
Em Thu, Jan 31, 2008 at 06:17:20PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Jan 31, 2008 at 08:57:53PM +0100, Eric Dumazet escreveu:
> > Hum... retrans_out should sit close to packets_out (or lost_out/sacked_out
> > ???), please.
> >
> > 'struct tcp_sock' is very large on 64 bits, so I
Andi Kleen wrote, On 01/31/2008 08:34 PM:
>> TSO by nature is bursty. But disabling TSO without the option of having
>> it on or off to me seems to aggressive. If someone is using a qdisc
>> that TSO is interfering with the effectiveness of the traffic shaping,
>> then they should turn off TSO v
Em Thu, Jan 31, 2008 at 08:57:53PM +0100, Eric Dumazet escreveu:
> Arnaldo Carvalho de Melo a écrit :
>> /home/acme/git/net-2.6/net/ipv6/tcp_ipv6.c:
>> struct tcp_sock | -16
>> struct tcp6_sock | -16
>> 2 structs changed
>>
>> Now it is at:
>>
>> /* size: 1552, cachelines: 25 */
>> /* paddi
In article <[EMAIL PROTECTED]> (at Fri, 01 Feb 2008 06:56:10 +1100 (EST)),
YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> says:
> Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> ---
> include/linux/if_addrlabel.h | 32 +
> ip/Makefile |2 +-
> ip/ip.c
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
---
include/linux/if_addrlabel.h | 32 +
ip/Makefile |2 +-
ip/ip.c |5 +-
ip/ip_common.h |4 +
ip/ipaddrlabel.c | 260 ++
Arnaldo Carvalho de Melo a écrit :
/home/acme/git/net-2.6/net/ipv6/tcp_ipv6.c:
struct tcp_sock | -16
struct tcp6_sock | -16
2 structs changed
Now it is at:
/* size: 1552, cachelines: 25 */
/* paddings: 2, sum paddings: 8 */
/* last cacheline: 16 bytes */
As soon as we stop using skb_qu
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
---
include/linux/if_addrlabel.h | 32 +
ip/Makefile |2 +-
ip/ip.c |5 +-
ip/ip_common.h |4 +
ip/ipaddrlabel.c | 260 ++
Hi Auke,
Based on the discussion in this thread, I am inclined to believe that
lack of PCI-e bus bandwidth is NOT the issue. The theory is that the
extra packet handling associated with TCP acknowledgements are pushing
the PCI-e x1 bus past its limits. However the evidence seems to show
otherw
> The philosophical problem I have with this suggestion is that
> I expect that the large majority of users will be more happy
> with disabled TSO if they use non standard qdiscs and
> defaults that do not fit the majority use case are bad.
>
> Basically you're suggesting that nearly everyone u
Hi Bill,
I see similar results on my test systems
Thanks for this report and for confirming our observations. Could you
please confirm that a single-port bidrectional UDP link runs at wire
speed? This helps to localize the problem to the TCP stack or interaction
of the TCP stack with the e10
Bruce Allen wrote:
> Hi Auke,
>
> 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.
That eliminates bus bandwidth issues, probably, but small packets take
>>
This patch disables writeback in POHMELFS and creates all objects
on behalf of its own without sync with remote side.
This mode is _very_ fast.
If POHEMLFS would be bound to single remote filesystem, it could
use its inode allocation policy and be very happy with write-back cache.
By design POHMEL
Hi.
POHMELFS stands for Parallel Optimized Host Message Exchange
Layered File System. It allows to mount remote servers to local
directory via network. This filesystem supports local caching
and writeback flushing.
POHMELFS is a brick in a future distributed filesystem.
This set includes two patc
Andi Kleen wrote:
So, at what timescale do people using these qdiscs expect things to
appear "smooth?" 64KB of data at GbE speeds is something just north of
half a millisecond unless I've botched my units somewhere.
One typical use case for TBF is you talking to a DSL bridge that
is connect
Hi Auke,
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.
That eliminates bus bandwidth issues, probably, but small packets take
up a lot of extra descriptors, bus bandwidth, CPU
Hello,
this patch is an (incomplete and probably wrong) attempt to convert 3c509
driver to isa_driver and pnp_driver model. It works but is not finished. My
original goal was to make 3c509 resume correctly after hibernation - this
still does not work (in fact, now it hangs during hibernation - I
Siim Põder <[EMAIL PROTECTED]> wrote:
>Jay Vosburgh wrote:
>> Benny Amorsen <[EMAIL PROTECTED]> wrote:
>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=430391
>>
>> I know what this is, I'll fix it.
>
>do you know when this happend, so we would know which kernel is ok to
>use (not to star
Sounds like tools to show PCI* bus utilization would be helpful...
that would be a hardware profiling thing and highly dependent on the part
sticking
out of the slot, vendor bus implementation etc... Perhaps Intel has some tools
for
this already but I personally do not know of any :/
Small
> TSO by nature is bursty. But disabling TSO without the option of having
> it on or off to me seems to aggressive. If someone is using a qdisc
> that TSO is interfering with the effectiveness of the traffic shaping,
> then they should turn off TSO via ethtool on the target device. Some
The phi
On Thu, Jan 31, 2008 at 07:46:02PM +0100, Patrick McHardy wrote:
> Patrick McHardy wrote:
>> Andi Kleen wrote:
>>
>>> Can you please try with the above config?
>> I'll give it a try later.
>
>
> I took all options from that config that seemed possibly
> related (qdiscs, no hrtimers, no nohz, slab,
> My point was that without TSO different submitters will
> interleave their streams (because they compete about the
> qdisc submission) and then you end up with a smooth rate over
> time for all of them.
>
> If you submit in large chunks only (as TSO does) it will
> always be more bursty and
Rick Jones wrote:
>> A lot of people tend to forget that the pci-express bus has enough
>> bandwidth on
>> first glance - 2.5gbit/sec for 1gbit of traffix, but apart from data
>> going over it
>> there is significant overhead going on: each packet requires transmit,
>> cleanup and
>> buffer transac
> So, at what timescale do people using these qdiscs expect things to
> appear "smooth?" 64KB of data at GbE speeds is something just north of
> half a millisecond unless I've botched my units somewhere.
One typical use case for TBF is you talking to a DSL bridge that
is connected using a GBit
Andi Kleen wrote:
On Thu, Jan 31, 2008 at 07:21:20PM +0100, Patrick McHardy wrote:
Andi Kleen wrote:
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
>from different streams to get everything fair and smooth. The only
Patrick McHardy wrote:
Andi Kleen wrote:
Can you please try with the above config?
I'll give it a try later.
I took all options from that config that seemed possibly
related (qdiscs, no hrtimers, no nohz, slab, ...), but
still can't reproduce it.
Does it also crash if you use more reason
A lot of people tend to forget that the pci-express bus has enough bandwidth on
first glance - 2.5gbit/sec for 1gbit of traffix, but apart from data going over
it
there is significant overhead going on: each packet requires transmit, cleanup
and
buffer transactions, and there are many irq regist
Andi Kleen wrote:
On Thu, Jan 31, 2008 at 10:26:19AM -0800, Rick Jones wrote:
Andi Kleen wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for soc
/home/acme/git/net-2.6/net/ipv6/tcp_ipv6.c:
struct inet_timewait_sock | -8
struct tcp_timewait_sock | -8
2 structs changed
tcp_v6_rcv| -6
1 function changed, 6 bytes removed, diff: -6
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
include/net/inet_t
/home/acme/git/net-2.6/net/dccp/ipv6.c:
struct ipv6_mc_socklist | -8
1 struct changed
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
include/net/if_inet6.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/if_inet6.h b/include/net/if_inet6
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6
Best Regards,
- Arnaldo
include/linux/dccp.h |2 -
include/linux/tcp.h|6 ++-
include/net/if_inet6.h |4 +-
include/net/inet6_hashtabl
/home/acme/git/net-2.6/net/ipv6/tcp_ipv6.c:
struct tcp_sock | -16
struct tcp6_sock | -16
2 structs changed
Now it is at:
/* size: 1552, cachelines: 25 */
/* paddings: 2, sum paddings: 8 */
/* last cacheline: 16 bytes */
As soon as we stop using skb_queue_list we'll get it down to 24 cach
And make it a multiple of a 64 bytes, reducing cacheline trashing:
Before:
[EMAIL PROTECTED] net-2.6]$ pahole -C inet6_dev net/dccp/ipv6.o
struct inet6_dev {
long unsigned int mc_maxdelay; /*48 8 */
unsigned char mc_qrv;
This way we can remove TCP and DCCP specific versions of
sk->sk_prot->get_port: both v4 and v6 use inet_csk_get_port
sk->sk_prot->hash: inet_hash is directly used, only v6 need
a specific version to deal with mapped sockets
sk->sk_prot->unhash: both v4 and v6 use inet_
/home/acme/git/net-2.6/net/dccp/ipv6.c:
struct dccp_sock | -8
struct dccp6_sock | -8
2 structs changed
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
include/linux/dccp.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/dccp.h b/in
On Thu, Jan 31, 2008 at 10:26:19AM -0800, Rick Jones wrote:
> Andi Kleen wrote:
> >TSO interacts badly with many queueing disciplines because they rely on
> >reordering packets from different streams and the large TSO packets can
> >make this difficult. This patch disables TSO for sockets that se
Bill Fink wrote:
> a 2.6.15.4 kernel. The GigE NICs are Intel PRO/1000
> 82546EB_QUAD_COPPER,
> on a 64-bit/133-MHz PCI-X bus, using version 6.1.16-k2 of the e1000
> driver, and running with 9000-byte jumbo frames. The TCP congestion
> control is BIC.
Bill, FYI, there was a known issue with e10
On Thu, Jan 31, 2008 at 07:21:20PM +0100, Patrick McHardy wrote:
> Andi Kleen wrote:
> >>Then change TBF to use skb_gso_segment? Be careful, the fact that
> >
> >That doesn't help because it wants to interleave packets
> >from different streams to get everything fair and smooth. The only
> >good
Andi Kleen wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for sockets that send over
devices with non standard queueing disciplines. That's anythi
Andi Kleen wrote:
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to handle that is to split it up and the simplest way to do
this is to just
> Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to handle that is to split it up and the simplest way to do
this is to just tell TCP to not do
Carsten Aulbert wrote:
> Hi Andi,
>
> Andi Kleen wrote:
>> Another issue with full duplex TCP not mentioned yet is that if TSO is
>> used the output will be somewhat bursty and might cause problems with
>> the TCP ACK clock of the other direction because the ACKs would need
>> to squeeze in betwe
Bruce Allen wrote:
> 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
1 - 100 of 199 matches
Mail list logo
