On Fri, 2006-07-14 at 12:12 -0400, Dan Reader wrote:
If we implement the approach you suggest and all data sent uses TSO, the
receiver can easily determine the expected codepoint of almost any
isolated CE packet. It simply has to look at the segment before and the
segment after (which it can
My take is that the ECT code point should also be replicated on
all TSO segments. When RFC3540 is implemented, the stack will
randomly use ECT(0) or ECT(1) on the TSO super segments. On
each of these super segments, the hardware will replicate the ECT
code point. This will keep
transmissions).
Ravi
-Original Message-
From: David Miller [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 08, 2006 1:32 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
netdev@vger.kernel.org
Subject: Re: [PATCH]NET: Add ECN support for TSO
From: Michael Chan [EMAIL PROTECTED
Ravinandan Arakali wrote:
But one of the issues is the random/pseudo-random generation of
ECT code points on each of these segments.
My take is that the ECT code point should also be replicated on
all TSO segments. When RFC3540 is implemented, the stack will
randomly use ECT(0) or ECT(1) on
From: Michael Chan [EMAIL PROTECTED]
Date: Thu, 13 Jul 2006 12:35:37 -0700
When RFC3540 is implemented, the stack will randomly use ECT(0) or
ECT(1) on the TSO super segments. On each of these super segments,
the hardware will replicate the ECT code point. This will keep
everything
Thanks.. I will get rid of the per-session check for ECN.
Ravi
-Original Message-
From: David Miller [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 11, 2006 11:12 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
netdev@vger.kernel.org
Subject: Re: [PATCH]NET: Add ECN
: Saturday, July 08, 2006 1:32 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
netdev@vger.kernel.org
Subject: Re: [PATCH]NET: Add ECN support for TSO
From: Michael Chan [EMAIL PROTECTED]
Date: Fri, 7 Jul 2006 18:01:34 -0700
However, Large Receive Offload will be a different story
From: Ravinandan Arakali [EMAIL PROTECTED]
Date: Tue, 11 Jul 2006 18:45:48 -0700
tk = tcp_sk(skb-sk);
if (tk-ecn_flags TCP_ECN_OK)
/* Check CE, ECE, CWR etc */
I find that skb-sk is NULL. Is this the correct way to check the
per-session
ECN capability ? Why is skb-sk NULL ?
On
David Miller wrote:
On receive? There is no reason for skb-sk to be anything other than
NULL on receive, the networking stack hasn't even seen the packet yet.
Only the driver has seen the skb.
Yeah, here's roughly how LRO should work for ECN:
If CE, ECE, or CWR is set on an incoming
From: Michael Chan [EMAIL PROTECTED]
Date: Fri, 7 Jul 2006 18:01:34 -0700
However, Large Receive Offload will be a different story. If
packets are accumulated in the hardware and presented to the stack
as one large packet, the stack will not be able to calculate the
cumulative NS correctly.
Michael,
Are network cards expected to be aware-of and implement RFC3540(ECN with
nonces) ?
Thanks,
Ravi
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Michael Chan
Sent: Tuesday, June 27, 2006 8:07 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc:
From: Michael Chan [EMAIL PROTECTED]
Date: Fri, 7 Jul 2006 13:57:11 -0700
RFC3540 is still experimental I believe and it is not implemented
in the Linux stack. Even if it is implemented and the NS bit is set,
I think the TSO logic can simply replicate the NS bit as each TSO
divided segment
From: David Miller [EMAIL PROTECTED]
Date: Fri, 07 Jul 2006 14:59:32 -0700 (PDT)
From: Michael Chan [EMAIL PROTECTED]
Date: Fri, 7 Jul 2006 13:57:11 -0700
RFC3540 is still experimental I believe and it is not implemented
in the Linux stack. Even if it is implemented and the NS bit is
From: Michael Chan [EMAIL PROTECTED]
Date: Tue, 27 Jun 2006 21:37:01 -0700
[NET]: Add ECN support for TSO
Applied, thanks a lot.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, Jun 27, 2006 at 08:06:47PM -0700, Michael Chan wrote:
diff --git a/include/net/sock.h b/include/net/sock.h
index 2d8d6ad..2c75172 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1033,7 +1033,8 @@ static inline void sk_setup_caps(struct
if (sk-sk_route_caps
On Tue, Jun 27, 2006 at 08:40:34PM -0700, Michael Chan wrote:
We need to turn off NETIF_F_TSO for a connection that has negotiated to
turn on ECN if the output device cannot handle TSO and ECN. In other
words, if the output device does not have either GSO or TSO_ECN feature
set.
I think
On Wed, 2006-06-28 at 13:48 +1000, Herbert Xu wrote:
I think you're mixing up GSO the mechanism with GSO the flag. The GSO
flag simply tells the TCP stack whether TSO should be used or not, even
if the hardware does not support TSO at all. The GSO mechanism on the
other hand is ALWAYS
On Tue, Jun 27, 2006 at 09:37:01PM -0700, Michael Chan wrote:
Signed-off-by: Michael Chan [EMAIL PROTECTED]
Looks good to me too!
@@ -56,6 +55,9 @@ static inline void TCP_ECN_send(struct s
if (tp-ecn_flagsTCP_ECN_QUEUE_CWR) {
tp-ecn_flags
On Wed, 2006-06-28 at 14:42 +1000, Herbert Xu wrote:
On Tue, Jun 27, 2006 at 09:37:01PM -0700, Michael Chan wrote:
@@ -56,6 +55,9 @@ static inline void TCP_ECN_send(struct s
if (tp-ecn_flagsTCP_ECN_QUEUE_CWR) {
tp-ecn_flags =
On Tue, Jun 27, 2006 at 09:54:39PM -0700, Michael Chan wrote:
Assuming that we'll later have GSO_TCPV6, isn't it better to check for
TCPV4 explicitly now? Or just change it later when necessary.
Good point, I suppose you never know whether a V6 TSO-capable card is going
to handle ECN
20 matches
Mail list logo
