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
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: netdev@vge
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->
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 pr
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
24 matches
Mail list logo
