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
> 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 every
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 s
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
endpoints and on non-TSO 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
Fro
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
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 11 Jul 2006 21:53:42 -0700
> There is no reason to find out if ECN is enabled or not for any
> TCP connections. Hw just needs to watch the above bits in the
> incoming packets.
Correct, it can be done in a completely stateless manner.
-
To unsu
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 incomi
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 NU
[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]>
Date: Fri, 7 Jul 2006 18:01:34 -0700
> Howev
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 corr
David Miller wrote:
> Ok, this is correct. TSO should simply replicate the NS bit
> because the cumulative ACK is going to be the same in each
> and every packet emitted.
>
>
Thanks for verifying. However, Large Receive Offload will be
a different story. If packets are accumulated in the har
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 N
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 se
Ravinandan Arakali wrote:
> Michael,
> Are network cards expected to be aware-of and implement
> RFC3540(ECN with
> nonces) ?
>
Hi Ravi,
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
@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: 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 http://vger.kernel.org/m
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 correc
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_flags&TCP_ECN_QUEUE_CWR) {
> > tp->ecn_flags &= ~TCP_E
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_flags&TCP_ECN_QUEUE_CWR) {
> tp->
er hand is ALWAYS 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 supp
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:10 +1000, Herbert Xu wrote:
> 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 @@ sta
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
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
25 matches
Mail list logo
