All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, gospo@redhat.com,
	bphilips@novell.com
Subject: Re: [PATCH 1/2] igb.txt: Add igb documentation
Date: Wed, 04 Aug 2010 03:34:34 +0100	[thread overview]
Message-ID: <1280889274.13192.565.camel@localhost> (raw)
In-Reply-To: <20100804001429.6571.95116.stgit@localhost.localdomain>

On Tue, 2010-08-03 at 17:15 -0700, Jeff Kirsher wrote:
[...]
> +  Jumbo Frames
> +  ------------
> +  Jumbo Frames support is enabled by changing the MTU to a value larger than
> +  the default of 1500.  Use the ifconfig command to increase the MTU size.
> +  For example:
> +
> +       ifconfig eth<x> mtu 9000 up
> +
> +  This setting is not saved across reboots.  

Not igb-specific.

[...]
> +  Ethtool
> +  -------
> +  The driver utilizes the ethtool interface for driver configuration and
> +  diagnostics, as well as displaying statistical information.  Ethtool
> +  version 3.0 or later is required for this functionality, although we 
> +  strongly recommend downloading the latest version at:
> +
> +  http://sourceforge.net/projects/gkernel.

Not igb-specific, and seriously - 3.0?

> +  Enabling Wake on LAN* (WoL)
> +  ---------------------------
> +  WoL is configured through the Ethtool* utility. 

Not igb-specific.

[...]
> +  LRO
> +  ---
> +  Large Receive Offload (LRO) is a technique for increasing inbound throughput
> +  of high-bandwidth network connections by reducing CPU overhead. It works by
> +  aggregating multiple incoming packets from a single stream into a larger 
> +  buffer before they are passed higher up the networking stack, thus reducing
> +  the number of packets that have to be processed. LRO combines multiple 
> +  Ethernet frames into a single receive in the stack, thereby potentially 
> +  decreasing CPU utilization for receives.

Not igb-specific.

> +  NOTE: LRO requires 2.6.24 or later kernel version.
[...]

Which is irrelevant to an in-tree driver.

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.


  parent reply	other threads:[~2010-08-04  2:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-04  0:15 [PATCH 1/2] igb.txt: Add igb documentation Jeff Kirsher
2010-08-04  0:16 ` [PATCH 2/2] igbvf.txt: Add igbvf Documentation Jeff Kirsher
2010-08-08  6:01   ` David Miller
2010-08-09  0:25     ` Jeff Kirsher
2010-08-04  0:39 ` [PATCH 1/2] igb.txt: Add igb documentation Joe Perches
2010-08-04  0:43   ` Jeff Kirsher
2010-08-04  2:34 ` Ben Hutchings [this message]
2010-08-05  4:20   ` Jeff Kirsher

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=1280889274.13192.565.camel@localhost \
    --to=bhutchings@solarflare.com \
    --cc=bphilips@novell.com \
    --cc=davem@davemloft.net \
    --cc=gospo@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.