All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: raj ravi <mekaviraj@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: GSO / TSO offload dependency
Date: Sun, 28 Feb 2010 19:30:46 +0000	[thread overview]
Message-ID: <1267385446.2282.119.camel@localhost> (raw)
In-Reply-To: <de0a9dcb1002280900k728b241fyd72112defc0336ea@mail.gmail.com>

On Sun, 2010-02-28 at 22:30 +0530, raj ravi wrote:
> Hi,
> I m currently working on TSO feature in Linux network driver.
> 
> Please correct my understanding.
> 
> GSO - Generic segmentation offload - does not require any hardware support.
> 
> TSO - TCP segmentation offload  - does require hardward support
> 
> 
> Does TSO needs GSO to be turned on?  OR in other words,  can I have
> GSO disabled and TSO Enabled ?
> I beleive the code is tied between both offload...but not sure about
> the above possibility... please clarify.

Segmentation/fragmentation can be done in one of three places:
1. By the transport protocol, when constructing skbs to be queued
2. By the transport protocol, when an skb is about to be passed to the
device (enabled by NETIF_F_GSO)
3. By the device driver and hardware (enabled by NETIF_F_TSO,
NETIF_F_UFO, etc.)

Depending on the context, 'GSO' can refer either to case 2, or to both
cases 2 and 3.  TSO does not need the NETIF_F_GSO feature to be turned
on, but in some contexts it is considered to be included in GSO.

> Just before handing over the packets to the Network driver,
> segmentation is carried out a call to dev_gso_segment ( ) function.
> Given GSO is enabled, It will take care about creating TCP and other
> protocol  segments  too,  even if TSO is disabled.. ..correct ?

Correct.

> If hardware supports TSO, and  If TSO and GSO are both enabled, ...
> what will happen to segmentation assembly by means of GSO ...
> GSO will not do any segmentatoin assembly for TCP alone and will do
> for other protocols ??  bit confused here? Please clarify.

Your understanding is correct.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


  reply	other threads:[~2010-02-28 19:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-28 17:00 GSO / TSO offload dependency raj ravi
2010-02-28 19:30 ` Ben Hutchings [this message]
2013-06-05  9:28   ` Deepak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1267385446.2282.119.camel@localhost \
    --to=bhutchings@solarflare.com \
    --cc=mekaviraj@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.