Re: behavior of TSO in kernel

Re: behavior of TSO in kernel

[Radha Mohan]

David,

I think we do not need to do this when TSO is enabled.

At line 1562 in tcp_output.c (in tcp_write_xmit() function)

    if (tso_segs > 1 && !tcp_urg_mode(tp))
           limit = tcp_mss_split_point(sk, skb, mss_now,
                                            cwnd_quota);
    if (skb->len > limit &&
                    unlikely(tso_fragment(sk, skb, limit, mss_now)))

Since the hardware can split and send the packet, there is 
no need for this in software.

Am I missing something here?

-- Mohan



----- Original Message ----
From: Radha Mohan <radhamohan_ch@yahoo.com>
To: netdev@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
Sent: Saturday, 6 June, 2009 7:41:21 PM
Subject: Re: behavior of TSO in kernel


>The TSO engine of the networking has been rewritten at least
>3 times since 2.6.15
Thank you for the info.
Actually we are working on an SoC and we just started moving from kernel 2.6.15, so can you tell me from which kernel version the latest TSO engine is being used. That'll make our life easier and avoid moving kernels frequently. Currently we are thinking of moving to 2.6.24. Will that do??


      ICC World Twenty20 England &#39;09 exclusively on YAHOO! CRICKET http://cricket.yahoo.com

Re: behavior of TSO in kernel

[Ilpo Järvinen]

On Sat, 6 Jun 2009, Radha Mohan wrote:

> >The TSO engine of the networking has been rewritten at least
> >3 times since 2.6.15
> Thank you for the info.
> Actually we are working on an SoC and we just started moving from kernel 
> 2.6.15, so can you tell me from which kernel version the latest TSO 
> engine is being used. That'll make our life easier and avoid moving 
> kernels frequently. Currently we are thinking of moving to 2.6.24. Will 
> that do??   

There are at least some fixes since that time too... Besides, I'd 
recommend you staying away from 2.6.24 anyway because it is rather
broken on TCP side too (and was already obsolete when the problem was 
discovered so it was never fixed)...

What is the problem in starting with a very recent kernel such as the 
almost released 2.6.30 or the current stable 2.6.29? Another alternative 
you might want to consider the long supported version 2.6.27 (IIRC, check 
the archives whether it was .27 or .28). However, if there's even 
a slightest consideration of submitting your changes into mainline, the
latest is the best choice, and keeping up with the upstream during the 
development is certainly my recommendation too (with git it should be 
rather straightforward to handle that).


-- 
 i.

Re: behavior of TSO in kernel

[Radha Mohan]

>The TSO engine of the networking has been rewritten at least
>3 times since 2.6.15
Thank you for the info.
Actually we are working on an SoC and we just started moving from kernel 2.6.15, so can you tell me from which kernel version the latest TSO engine is being used. That'll make our life easier and avoid moving kernels frequently. Currently we are thinking of moving to 2.6.24. Will that do??


      Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/

Re: behavior of TSO in kernel

[David Miller]

From: Radha Mohan <radhamohan_ch@yahoo.com>
Date: Fri, 5 Jun 2009 20:09:10 +0530 (IST)

> I have an ethernet driver with TSO, SG, IP_CSUM features enabled. I
> am using linux-2.6.15 kernel. The MTU is set to 9014. It seems the
> driver is getting skbs of only 9014 bytes length even though the
> application is able to write some 64KB at a time.

The TSO engine of the networking has been rewritten at least
3 times since 2.6.15

You're asking us how code worked three major rewrites ago and
nobody is going to help you without some kind of paid support
contract from a Linux support vendor, sorry.

behavior of TSO in kernel

[Radha Mohan]

Hi all,

I have an ethernet driver with TSO, SG, IP_CSUM features enabled. I am using linux-2.6.15 kernel. The MTU is set to 9014. It seems the driver is getting skbs of only 9014 bytes length even though the application is able to write some 64KB at a time. 

Why is TCP layer doing the segmentation when we said TSO is enabled by giving NETIF_F_TSO?

I saw tcp_sendmsg() function, and found that never an skb->len can be more than 12K since there is a check that if it exceeds "mss_now" then either tcp_push_one() or tcp_push() is called. If I further see the tcp_push_one() function, there we calculate the "limit" and further trim the skb->len in tso_fragment().

In another function, tcp_write_xmit() also similar behaviour is present.

What I do not understand is why should TCP layer do all these in software when there is TSO in hardware? Why can't a driver get a bigger packet of say 64K or something larger than current MSS assuming there is enough window for sending it?

I have briefly checked 2.6.24 kernel but here also it is the same. 


-- Mohan


      Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/