From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Sun, 21 Aug 2005 16:35:06 -0700 (PDT)
> Attached are two patches dealing with two issues I think should be
> addressed in 2.6.13 if possible.
Sorry, I attached the wrong patches, let's try this instead.
diff-tree b94c07bcb646075b82302616c369b1f30
Attached are two patches dealing with two issues I think should be
addressed in 2.6.13 if possible.
The first patch is the TSO deferral logic fix from Dmitry Yusupov. I
think it's correct since even if no new data is tacked on, we will
keep the pipe filled to the end since the percentage-of-wind
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 01:13:21 +0200
> > Basically, you'll have skb->free_callback(skb, ARG), and
> > skb->free_callback_ARG. And when the SKB and it's memory
> > is about to get liberated, we'll call the callback instead
> > of doing the free if the callback
From: Guy Thornley <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 11:06:13 +1200
> Does the 2.4 kernel support chained sk_buff's along the receive path? (This
> is news to me!) Is there any driver that does this, that can be read as an
> instructive example?
It does, just that no driver takes advanta
>
> Basically, you'll have skb->free_callback(skb, ARG), and
> skb->free_callback_ARG. And when the SKB and it's memory
> is about to get liberated, we'll call the callback instead
> of doing the free if the callback is non-NULL.
One issue is that the NIC focus shouldn't be reprogrammed for ever
On Fri, Aug 19, 2005 at 07:05:06PM +0200, Andi Kleen wrote:
> > Right. The other issue with jumbos frames (9000MTU) is that
> > the allocation needed is just over 2 pages for 4K page size
> > machines (common case). 3 page contig allocations tend to fail
> > once a server is heavily loaded and memo
> -Original Message-
> From: David S. Miller [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 21, 2005 3:34 PM
> We'll be adding the RX free callback support soon, perhaps in
> the 2.6.14 timeframe, once we shrink the sk_buff struct a
> little bit more so that we can justify adding t
On Sun, Aug 21, 2005 at 03:33:36PM -0700, David S. Miller wrote:
> From: "Leonid Grossman" <[EMAIL PROTECTED]>
> Date: Sun, 21 Aug 2005 13:02:00 -0400
>
> > Andi, can you provide a callback patch please?
>
> Andi isn't very active in the networking these days,
> so asking him to do the work whil
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Sun, 21 Aug 2005 23:38:24 +0100
> Does it really need to be in the skbuff? I I think a
> rx_free_skb method in struct net_device would be sufficient.
The device on the SKB can be changed long before we free
it, due to netfilter, traffic classific
From: "Leonid Grossman" <[EMAIL PROTECTED]>
Date: Sun, 21 Aug 2005 13:02:00 -0400
> Andi, can you provide a callback patch please?
Andi isn't very active in the networking these days,
so asking him to do the work whilst he's so busy with
x86_64 maintainence isn't the best idea :)
We'll be addin
All other things being equal, it is better not to put packets into the
network faster than it can drain them out. Large bursts increase delay
variation, and increase the probability that two or more packets in a
connection will be dropped within an RTT (not every box is implementing
AQM yet). Ne
On Sun, 21 Aug 2005, David S. Miller wrote:
> LRO will work, and it's the negative attitude of the TOE folks that
> inspires me to want to help out the LRO folks and ignore the TOE mania
> altogether.
Dave you critized the black and white attitude before. It seems that you
are the only one in th
David S. Miller wrote:
> From: "Wael Noureddine" <[EMAIL PROTECTED]>
> Date: Sun, 21 Aug 2005 00:17:17 -0700
>
>
>>How do you intend on avoiding huge stretch ACKs?
>
>
> The implication is that stretch ACKs are bad, which is wrong.
> Oh yes, that's right, you're the same person who earlier in t
> -Original Message-
> From: Christoph Lameter [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 21, 2005 9:28 AM
> To: David S. Miller
> Cc: [EMAIL PROTECTED]; Leonid Grossman; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PR
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 21, 2005 9:36 AM
> To: David S. Miller
> Cc: Leonid Grossman; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED
> If you have a flow cache, keyed on saddr/daddr/sport/dport then you
> can keep a growing LRO limit. For example, when a flow cache entry is
> created, use a LRO limit of 2 frames. Each time the LRO limit is
> reached, increase the LRO limit by one (until you hit the largest
> LRO supported, whi
David S. Miller wrote:
> From: "Wael Noureddine" <[EMAIL PROTECTED]>
> Date: Sun, 21 Aug 2005 00:54:51 -0700
>
>
>>>You could also tweak the LRO timeout in a similar fashion based upon
>>>traffic patterns as well. In fact, extremely sophisticated things can
>>>be done here to deal with the LRO t
LRO will just stop accumulating when out-of-sequence data arrives.
Nothing complicated at all.
Unless the NIC keeps state, it is not always able to know if data is out of
sequence.
The LRO timing is not complicated, the packet limit is simply a
linearly increasing value that just makes sure
On Sun, 2005-08-21 at 01:53 -0700, Wael Noureddine wrote:
> >> How do you intend on avoiding huge stretch ACKs?
> >
> > The implication is that stretch ACKs are bad, which is wrong.
> > Oh yes, that's right, you're the same person who earlier in this
> > thread tried to teach us that bursty TCPs ar
Danial Thom <[EMAIL PROTECTED]> wrote:
>
> I just started fiddling with 2.6.12, and there
> seems to be a big drop-off in performance from
> 2.4.x in terms of networking on a uniprocessor
> system. Just bridging packets through the
> machine, 2.6.12 starts dropping packets at
> ~100Kpps, whereas 2.
hii ..
Can anyone help me in figuring out that whether the linux 2.6 kernel has
got a
way for ICMP handling for IPsec/Ipv4 or not.If yes plzz tell me the files
whether its done... Or just guide me a lil in short whether the 2.6 kernel
has successfull handling of PMTU for IPsec/Ipv4 n where they r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David S. Miller wrote:
> IPSEC/NAT will be done very differently from Patrick's old patches,
> and in fact these hacks which you are adding are side effects of
> the flaws in the original approach made in the IPSEC/NAT patches.
>
> I really cannot con
[EMAIL PROTECTED] wrote:
Sorry the last 3 mails were duplicates off the first,
I though my mail server had rejected them,
I suggest to take this to netfilter-devel, people there have
more experience using ip_queue. And please include some more
information, like iptables rules, iptables modules
Sorry the last 3 mails were duplicates off the first,
I though my mail server had rejected them,
Apologies,
Kevin
> Hello all,
> I'm writing an application which forwards incoming packets
> depending on the applications current view of the network. All
> packets are sent to userpace with N
Hello all,
I'm writing an application which forwards incoming packets
depending on the applications current view of the network. All
packets are sent to userpace with NF_QUEUE (this was suggested to
me by this list and its working great for single hops, thanks :-)).
So iphdr->daddr is eith
Hello all,
I'm writing an application which forwards incoming packets
depending on the applications current view of the network. All
packets are sent to userpace with NF_QUEUE (this was suggested to
me by this list and its working great for single hops, thanks :-)).
So iphdr->daddr is eith
Hello all,
I'm writing an application which forwards incoming packets
depending on the applications current view of the network. All
packets are sent to userpace with NF_QUEUE (this was suggested to
me by this list and its working great for single hops, thanks :-)).
So iphdr->daddr is eith
Hello list, Herbert!
> >
> > Aug 20 01:07:24 192.168.2.50 kernel: [42992885.04] []
> > __gnbd_send_req+0x196/0x28d [gnbd]
>
> Please talk to the GNBD people about this.
I know, you have right!
I get the same answer from linux-raid list.
But now I think I must ask you: Are you sure?
I use co
How do you intend on avoiding huge stretch ACKs?
The implication is that stretch ACKs are bad, which is wrong.
Oh yes, that's right, you're the same person who earlier in this
thread tried to teach us that bursty TCPs are non-standard :-)
Are you saying that burstiness is not an issue?
There i
Jay Vosburgh <[EMAIL PROTECTED]> wrote:
>
> >FWIW, this patch is currently being carried in the Fedora and RHEL
> >kernels. It certainly looks like it is necessary to me. Can we get
> >some movement on this?
>
> It's in the SuSE kernel as well.
For how long has this fix been in the ven
From: "Wael Noureddine" <[EMAIL PROTECTED]>
Date: Sun, 21 Aug 2005 00:54:51 -0700
> > You could also tweak the LRO timeout in a similar fashion based upon
> > traffic patterns as well. In fact, extremely sophisticated things can
> > be done here to deal with the LRO timing as seen on WAN vs. LAN
From: "Wael Noureddine" <[EMAIL PROTECTED]>
Date: Sun, 21 Aug 2005 00:17:17 -0700
> How do you intend on avoiding huge stretch ACKs?
The implication is that stretch ACKs are bad, which is wrong.
Oh yes, that's right, you're the same person who earlier in this
thread tried to teach us that bursty
On Sat, Aug 20, 2005 at 12:02:01PM +0200, [EMAIL PROTECTED] wrote:
>
> Aug 20 01:07:24 192.168.2.50 kernel: [42992885.04] []
> __gnbd_send_req+0x196/0x28d [gnbd]
Please talk to the GNBD people about this.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[E
You could also tweak the LRO timeout in a similar fashion based upon
traffic patterns as well. In fact, extremely sophisticated things can
be done here to deal with the LRO timing as seen on WAN vs. LAN
streams.
The accurate statement is "extremely complicated things need to be done here
to de
Date: Sat, 20 Aug 2005 21:55:22 -0700 (PDT)
I bet the tricks that we hack into the TCP/IP stack for LSO and for
LRO will turn out to be more difficult to maintain than the proposed
TOE hooks.
LRO is going to be mostly transparent.
How do you intend on avoiding huge stretch ACKs?
As far as
Christoph Lameter wrote:
On Sat, 20 Aug 2005, David S. Miller wrote:
But by in large, if a stateless alternative ever exists to
get the same performance benefit as TOE, it will undoubtedly
be preferred by the Linux networking maintainers, by in large.
So you TOE guys are fighting more than an up
36 matches
Mail list logo
