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.
@vger.kernel.org
Subject: [PATCH]NET: Add ECN support for TSO
In the current TSO implementation, NETIF_F_TSO and ECN cannot be
turned on together in a TCP connection. The problem is that most
hardware that supports TSO does not handle CWR correctly if it is set
in the TSO packet. Correct handling
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
In the current TSO implementation, NETIF_F_TSO and ECN cannot be
turned on together in a TCP connection. The problem is that most
hardware that supports TSO does not handle CWR correctly if it is set
in the TSO packet. Correct handling requires CWR to be set in the
first packet only if it is set
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
present. So regardless of the presence of the GSO
flag, you can always rely on the GSO mechanism to pick up the pieces (or
rather generate the pieces as the case may be :)
Thanks, that was my confusion. Here's the revised patch:
[NET]: Add ECN support for TSO
In the current TSO implementation
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
21 matches
Mail list logo