* Re: [GIT PULL] xen-netfront driver updates for 2.6.36
From: David Miller @ 2010-08-03 23:37 UTC (permalink / raw)
To: jeremy; +Cc: linux-kernel, netdev, Xen-devel, dongxiao.xu
In-Reply-To: <4C586271.3010902@goop.org>
From: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Tue, 03 Aug 2010 11:39:45 -0700
> Here's a git branch with some updates to the Xen netfront driver,
> which add a new "smartpoll" mode to the netfront backend protocol,
> which is basically equivalent to interrupt mitigation. This merges
> cleanly with current linux-next (it previously just had a small
> constification conflict).
>
> Do you want to take this via the net tree, or are you OK with me
> submitting them directly?
Well from my perspective:
1) It's too late to put into my tree because the merge window has
already started. If you want me to include this you should have
asked me to pull it in days if not weeks ago.
2) Your tree is absolutely not in a state I can pull it. It has lots
of completely unrelated commits which are not in net-next-2.6 which
in no way should I be pulling into my tree.
When you want me to take changes, your tree should be based upon mine.
And when I pull from your tree I should get only your specific
xen-netfront driver changes, and nothing more.
Thanks.
^ permalink raw reply
* Re: [PATCH v5] can: Add driver for esd CAN-USB/2 device
From: David Miller @ 2010-08-03 23:38 UTC (permalink / raw)
To: matthias.fuchs; +Cc: netdev, Socketcan-core, linux-usb
In-Reply-To: <201008031455.23255.matthias.fuchs@esd.eu>
From: Matthias Fuchs <matthias.fuchs@esd.eu>
Date: Tue, 3 Aug 2010 14:55:23 +0200
> This patch adds a driver for esd's USB high speed
> CAN interface. The driver supports devices with
> multiple CAN interfaces.
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Applied, thank you.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000e: correct MAC-PHY interconnect register offset for 82579
From: David Miller @ 2010-08-03 23:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100803214827.5712.8674.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 03 Aug 2010 14:48:35 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The MAC-PHY interconnect register set on ICH/PCH parts is accessed through
> a peephole mechanism by writing an offset to a CSR register. The offset
> for the interconnect's half-duplex control register (which is used in a
> jumbo frame workaround for 82579) is incorrect.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] igb: Program MDICNFG register prior to PHY init
From: David Miller @ 2010-08-03 23:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, alexander.h.duyck
In-Reply-To: <20100803215005.5948.63055.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 03 Aug 2010 14:50:08 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch addresses an issue seen on 82580 in which the MDICNFG
> register will be reset during a single function reset and as a
> result we will be unable to communicate with the PHY. To correct
> the issue, added a call to reset_mdicnfg just prior to the first
> access of the MDICNFG register in sgnii_uses_mdio.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH] hso: Add new product ID
From: David Miller @ 2010-08-03 23:41 UTC (permalink / raw)
To: f.aben-x9gZzRpC1QbQT0dZR+AlfA
Cc: gregkh-l3A5Bk7waGM, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1280849801.5149.5.camel@filip-linux>
From: Filip Aben <f.aben-x9gZzRpC1QbQT0dZR+AlfA@public.gmane.org>
Date: Tue, 03 Aug 2010 17:36:41 +0200
> This patch adds a new product ID to the hso driver.
>
> Signed-off-by: Filip Aben <f.aben-x9gZzRpC1QbQT0dZR+AlfA@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ipt_REJECT: can't work with bridges
From: Changli Gao @ 2010-08-03 23:54 UTC (permalink / raw)
To: Patrick McHardy
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, netfilter-devel, netdev,
Changli Gao
In-Reply-To: <1278314214-18469-1-git-send-email-xiaosuo@gmail.com>
On Mon, Jul 5, 2010 at 3:16 PM, Changli Gao <xiaosuo@gmail.com> wrote:
> ipt_REJECT: can't work with bridges
>
> ip_route_me_harder can't create the route cache when the outdev is the same with
> the indev for the skbs whichout a valid protocol set.
>
> __mkroute_input functions has this check:
> 1998 if (skb->protocol != htons(ETH_P_IP)) {
> 1999 /* Not IP (i.e. ARP). Do not create route, if it is
> 2000 * invalid for proxy arp. DNAT routes are always valid.
> 2001 *
> 2002 * Proxy arp feature have been extended to allow, ARP
> 2003 * replies back to the same interface, to support
> 2004 * Private VLAN switch technologies. See arp.c.
> 2005 */
> 2006 if (out_dev == in_dev &&
> 2007 IN_DEV_PROXY_ARP_PVLAN(in_dev) == 0) {
> 2008 err = -EINVAL;
> 2009 goto cleanup;
> 2010 }
> 2011 }
>
> This patch gives the new skb a valid protocol to bypass this check. In order to
> make ipt_REJECT work with bridges, you also need to enable ip_forward.
>
> This patch also fixes a regression. When we used skb_copy_expand(), we didn't
> have this issue stated above, as the protocol was properly set. In fact, the
> regression also affects TC classification and packet sockets.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ----
> net/ipv4/netfilter/ipt_REJECT.c | 1 +
> 1 file changed, 1 insertion(+)
> diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
> index bbbd273..60b8832 100644
> --- a/net/ipv4/netfilter/ipt_REJECT.c
> +++ b/net/ipv4/netfilter/ipt_REJECT.c
> @@ -111,6 +111,7 @@ static void send_reset(struct sk_buff *oldskb, int hook)
> /* ip_route_me_harder expects skb->dst to be set */
> skb_dst_set_noref(nskb, skb_dst(oldskb));
>
> + nskb->protocol = htons(ETH_P_IP);
> if (ip_route_me_harder(nskb, addr_type))
> goto free_nskb;
>
>
This bugfix patch seems missed, or I need to respin it? Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Greg KH @ 2010-08-03 23:56 UTC (permalink / raw)
To: Patrick Pannuto
Cc: linux-kernel, linux-arm-msm, linux-omap, damm, lethal, rjw, dtor,
eric.y.miao, netdev
In-Reply-To: <4C58A7AA.8020007@codeaurora.org>
On Tue, Aug 03, 2010 at 04:35:06PM -0700, Patrick Pannuto wrote:
> Inspiration for this comes from:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>
> INTRO
>
> As SOCs become more popular, the desire to quickly define a simple,
> but functional, bus type with only a few unique properties becomes
> desirable. As they become more complicated, the ability to nest these
> simple busses and otherwise orchestrate them to match the actual
> topology also becomes desirable.
>
> EXAMPLE USAGE
>
> /arch/ARCH/MY_ARCH/my_bus.c:
>
> #include <linux/device.h>
> #include <linux/platform_device.h>
>
> struct bus_type my_bus_type = {
> .name = "mybus",
> };
> EXPORT_SYMBOL_GPL(my_bus_type);
>
> struct platform_device sub_bus1 = {
> .name = "sub_bus1",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus1);
You really want a bus hanging off of a bus? Normally you need a device
to do that, which is what I think you have here, but the naming is a bit
odd to me.
What would you do with this "sub bus"? It's just a device, but you are
wanting it to be around for something.
>
> struct platform_device sub_bus2 = {
> .name = "sub_bus2",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus2);
>
> static int __init my_bus_init(void)
> {
> int error;
> platform_bus_type_init(&my_bus_type);
>
> error = bus_register(&my_bus_type);
> if (error)
> return error;
>
> error = platform_device_register(&sub_bus1);
> if (error)
> goto fail_sub_bus1;
>
> error = platform_device_register(&sub_bus2);
> if (error)
> goto fail_sub_bus2;
>
> return error;
>
> fail_sub_bus2:
> platform_device_unregister(&sub_bus1);
> fail_sub_bus2:
> bus_unregister(&my_bus_type);
>
> return error;
> }
> postcore_initcall(my_bus_init);
> EXPORT_SYMBOL_CPY(my_bus_init);
>
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = &my_bus_type,
> },
> };
>
> /somewhere/my_device.c
> static struct platform_device my_device = {
> .name = "my-device",
> .id = -1,
> .dev.bus = &my_bus_type,
> .dev.parent = &sub_bus_1.dev,
> };
Ah, you put devices on this "sub bus". But why? Why not just put it on
your "normal" bus that you created? What's with the extra level of
nesting here?
Other than that, it looks like a nice idea, are there portions of kernel
code that can be simplified because of this?
> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
> * if the probe was successful, and make sure any forced probes of
> * new devices fail.
> */
> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
> drv->probe = NULL;
> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
> retval = -ENODEV;
> drv->driver.probe = platform_drv_probe_fail;
> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
>
> if (code != retval)
> platform_driver_unregister(drv);
I'm guessing that this chunk can be applied now, right?
> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
> };
> EXPORT_SYMBOL_GPL(platform_bus_type);
>
> +/** platform_bus_type_init - fill in a pseudo-platform-bus
> + * @bus: foriegn bus type
> + *
> + * This init is basically a selective memcpy that
> + * won't overwrite any user-defined attributes and
> + * only copies things that platform bus defines anyway
> + */
> +void platform_bus_type_init(struct bus_type *bus)
> +{
> + if (!bus->dev_attrs)
> + bus->dev_attrs = platform_bus_type.dev_attrs;
> + if (!bus->match)
> + bus->match = platform_bus_type.match;
> + if (!bus->uevent)
> + bus->uevent = platform_bus_type.uevent;
> + if (!bus->pm)
> + bus->pm = platform_bus_type.pm;
Watch out for things in "write only" memory here. That could cause
problems.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Patrick Pannuto @ 2010-08-04 0:02 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, linux-arm-msm, linux-omap, damm, lethal, rjw, dtor,
eric.y.miao, netdev
In-Reply-To: <20100803235631.GA17759@suse.de>
On 08/03/2010 04:56 PM, Greg KH wrote:
> On Tue, Aug 03, 2010 at 04:35:06PM -0700, Patrick Pannuto wrote:
>> Inspiration for this comes from:
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>>
>> INTRO
>>
>> As SOCs become more popular, the desire to quickly define a simple,
>> but functional, bus type with only a few unique properties becomes
>> desirable. As they become more complicated, the ability to nest these
>> simple busses and otherwise orchestrate them to match the actual
>> topology also becomes desirable.
>>
>> EXAMPLE USAGE
>>
>> /arch/ARCH/MY_ARCH/my_bus.c:
>>
>> #include <linux/device.h>
>> #include <linux/platform_device.h>
>>
>> struct bus_type my_bus_type = {
>> .name = "mybus",
>> };
>> EXPORT_SYMBOL_GPL(my_bus_type);
>>
>> struct platform_device sub_bus1 = {
>> .name = "sub_bus1",
>> .id = -1,
>> .dev.bus = &my_bus_type,
>> }
>> EXPORT_SYMBOL_GPL(sub_bus1);
>
> You really want a bus hanging off of a bus? Normally you need a device
> to do that, which is what I think you have here, but the naming is a bit
> odd to me.
>
> What would you do with this "sub bus"? It's just a device, but you are
> wanting it to be around for something.
>
It's for power management stuff, basically, there are actual physical buses
involved that can be completely powered off IFF all of their devices are
not in use. Plus it actually matches bus topology this way.
>>
>> struct platform_device sub_bus2 = {
>> .name = "sub_bus2",
>> .id = -1,
>> .dev.bus = &my_bus_type,
>> }
>> EXPORT_SYMBOL_GPL(sub_bus2);
>>
>> static int __init my_bus_init(void)
>> {
>> int error;
>> platform_bus_type_init(&my_bus_type);
>>
>> error = bus_register(&my_bus_type);
>> if (error)
>> return error;
>>
>> error = platform_device_register(&sub_bus1);
>> if (error)
>> goto fail_sub_bus1;
>>
>> error = platform_device_register(&sub_bus2);
>> if (error)
>> goto fail_sub_bus2;
>>
>> return error;
>>
>> fail_sub_bus2:
>> platform_device_unregister(&sub_bus1);
>> fail_sub_bus2:
>> bus_unregister(&my_bus_type);
>>
>> return error;
>> }
>> postcore_initcall(my_bus_init);
>> EXPORT_SYMBOL_CPY(my_bus_init);
>>
>> /drivers/my_driver.c
>> static struct platform_driver my_driver = {
>> .driver = {
>> .name = "my-driver",
>> .owner = THIS_MODULE,
>> .bus = &my_bus_type,
>> },
>> };
>>
>> /somewhere/my_device.c
>> static struct platform_device my_device = {
>> .name = "my-device",
>> .id = -1,
>> .dev.bus = &my_bus_type,
>> .dev.parent = &sub_bus_1.dev,
>> };
>
> Ah, you put devices on this "sub bus". But why? Why not just put it on
> your "normal" bus that you created? What's with the extra level of
> nesting here?
>
> Other than that, it looks like a nice idea, are there portions of kernel
> code that can be simplified because of this?
See above.
>
>> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
>> * if the probe was successful, and make sure any forced probes of
>> * new devices fail.
>> */
>> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
>> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
>> drv->probe = NULL;
>> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
>> retval = -ENODEV;
>> drv->driver.probe = platform_drv_probe_fail;
>> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
>> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
>>
>> if (code != retval)
>> platform_driver_unregister(drv);
>
> I'm guessing that this chunk can be applied now, right?
Probably; right now this will always work since anything that
is a platform_driver will have .driver.bus = &platform_bus_type,
but that does change with this patch.
There is no need (IMHO) for it to be a separate patch.
>
>> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
>> };
>> EXPORT_SYMBOL_GPL(platform_bus_type);
>>
>> +/** platform_bus_type_init - fill in a pseudo-platform-bus
>> + * @bus: foriegn bus type
>> + *
>> + * This init is basically a selective memcpy that
>> + * won't overwrite any user-defined attributes and
>> + * only copies things that platform bus defines anyway
>> + */
>> +void platform_bus_type_init(struct bus_type *bus)
>> +{
>> + if (!bus->dev_attrs)
>> + bus->dev_attrs = platform_bus_type.dev_attrs;
>> + if (!bus->match)
>> + bus->match = platform_bus_type.match;
>> + if (!bus->uevent)
>> + bus->uevent = platform_bus_type.uevent;
>> + if (!bus->pm)
>> + bus->pm = platform_bus_type.pm;
>
> Watch out for things in "write only" memory here. That could cause
> problems.
Pardon my ignorance (I'm quite new to kernel work), what do you mean
here? What memory could be "write only"?
>
> thanks,
>
> greg k-h
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Greg KH @ 2010-08-04 0:09 UTC (permalink / raw)
To: Patrick Pannuto
Cc: linux-kernel, linux-arm-msm, linux-omap, damm, lethal, rjw, dtor,
eric.y.miao, netdev
In-Reply-To: <4C58AE15.6090900@codeaurora.org>
On Tue, Aug 03, 2010 at 05:02:29PM -0700, Patrick Pannuto wrote:
> On 08/03/2010 04:56 PM, Greg KH wrote:
> > On Tue, Aug 03, 2010 at 04:35:06PM -0700, Patrick Pannuto wrote:
> >> Inspiration for this comes from:
> >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
> >>
> >> INTRO
> >>
> >> As SOCs become more popular, the desire to quickly define a simple,
> >> but functional, bus type with only a few unique properties becomes
> >> desirable. As they become more complicated, the ability to nest these
> >> simple busses and otherwise orchestrate them to match the actual
> >> topology also becomes desirable.
> >>
> >> EXAMPLE USAGE
> >>
> >> /arch/ARCH/MY_ARCH/my_bus.c:
> >>
> >> #include <linux/device.h>
> >> #include <linux/platform_device.h>
> >>
> >> struct bus_type my_bus_type = {
> >> .name = "mybus",
> >> };
> >> EXPORT_SYMBOL_GPL(my_bus_type);
For your question below, this could be in write-only memory. Well, I
guess it never is as we modify things in the bus structure, so nevermind
about that, false alarm.
> >>
> >> struct platform_device sub_bus1 = {
> >> .name = "sub_bus1",
> >> .id = -1,
> >> .dev.bus = &my_bus_type,
> >> }
> >> EXPORT_SYMBOL_GPL(sub_bus1);
> >
> > You really want a bus hanging off of a bus? Normally you need a device
> > to do that, which is what I think you have here, but the naming is a bit
> > odd to me.
> >
> > What would you do with this "sub bus"? It's just a device, but you are
> > wanting it to be around for something.
> >
>
> It's for power management stuff, basically, there are actual physical buses
> involved that can be completely powered off IFF all of their devices are
> not in use. Plus it actually matches bus topology this way.
Then create a real bus hanging off of a device, not another device that
"acts" like a bus here, right? Or am I missing the point?
> >> +void platform_bus_type_init(struct bus_type *bus)
> >> +{
> >> + if (!bus->dev_attrs)
> >> + bus->dev_attrs = platform_bus_type.dev_attrs;
> >> + if (!bus->match)
> >> + bus->match = platform_bus_type.match;
> >> + if (!bus->uevent)
> >> + bus->uevent = platform_bus_type.uevent;
> >> + if (!bus->pm)
> >> + bus->pm = platform_bus_type.pm;
> >
> > Watch out for things in "write only" memory here. That could cause
> > problems.
>
> Pardon my ignorance (I'm quite new to kernel work), what do you mean
> here? What memory could be "write only"?
See above. I was thinking that struct bus would be a constant or
something. Sorry.
greg k-h
^ permalink raw reply
* [PATCH 1/2] igb.txt: Add igb documentation
From: Jeff Kirsher @ 2010-08-04 0:15 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, gospo, bphilips, Jeff Kirsher
Add documentation for the igb networking driver.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
---
Documentation/networking/igb.txt | 134 ++++++++++++++++++++++++++++++++++++++
1 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 Documentation/networking/igb.txt
diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt
new file mode 100644
index 0000000..975023a
--- /dev/null
+++ b/Documentation/networking/igb.txt
@@ -0,0 +1,134 @@
+Linux* Base Driver for Intel(R) Network Connection
+==================================================
+
+Intel Gigabit Linux driver.
+Copyright(c) 1999 - 2010 Intel Corporation.
+
+Contents
+========
+
+- Identifying Your Adapter
+- Additional Configurations
+- Support
+
+Identifying Your Adapter
+========================
+
+This driver supports all 82575, 82576 and 82580-based Intel (R) gigabit network
+connections.
+
+For specific information on how to identify your adapter, go to the Adapter &
+Driver ID Guide at:
+
+ http://support.intel.com/support/go/network/adapter/idguide.htm
+
+Command Line Parameters
+=======================
+
+The default value for each parameter is generally the recommended setting,
+unless otherwise noted.
+
+max_vfs
+-------
+Valid Range: 0-7
+Default Value: 0
+
+This parameter adds support for SR-IOV. It causes the driver to spawn up to
+max_vfs worth of virtual function.
+
+Additional Configurations
+=========================
+
+ 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.
+
+ Notes:
+
+ - The maximum MTU setting for Jumbo Frames is 9216. This value coincides
+ with the maximum Jumbo Frames size of 9234 bytes.
+
+ - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
+ loss of link.
+
+ 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.
+
+ Enabling Wake on LAN* (WoL)
+ ---------------------------
+ WoL is configured through the Ethtool* utility.
+
+ For instructions on enabling WoL with Ethtool, refer to the Ethtool man page.
+
+ WoL will be enabled on the system during the next shut down or reboot.
+ For this driver version, in order to enable WoL, the igb driver must be
+ loaded when shutting down or rebooting the system.
+
+ Wake On LAN is only supported on port A of multi-port adapters.
+
+ Wake On LAN is not supported for the Intel(R) Gigabit VT Quad Port Server
+ Adapter.
+
+ Multiqueue
+ ----------
+ In this mode, a separate MSI-X vector is allocated for each queue and one
+ for "other" interrupts such as link status change and errors. All
+ interrupts are throttled via interrupt moderation. Interrupt moderation
+ must be used to avoid interrupt storms while the driver is processing one
+ interrupt. The moderation value should be at least as large as the expected
+ time for the driver to process an interrupt. Multiqueue is off by default.
+
+ REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not
+ found, the system will fallback to MSI or to Legacy interrupts.
+
+ 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.
+
+ NOTE: LRO requires 2.6.24 or later kernel version. You also need to have
+ inet_lro enabled via either the CONFIG_INET_LRO or CONFIG_INET_LRO_MODULE
+ kernel config option. Additionally, if CONFIG_INET_LRO_MODULE is used, the
+ inet_lro module needs to be loaded before the igb driver.
+
+ You can verify that the driver is using LRO by looking at these counters in
+ Ethtool:
+
+ lro_aggregated - count of total packets that were combined
+ lro_flushed - counts the number of packets flushed out of LRO
+ lro_no_desc - counts the number of times an LRO descriptor was not available
+ for the LRO packet
+
+ NOTE: IPv6 and UDP are not supported by LRO.
+
+Support
+=======
+
+For general information, go to the Intel support website at:
+
+ www.intel.com/support/
+
+or the Intel Wired Networking project hosted by Sourceforge at:
+
+ http://sourceforge.net/projects/e1000
+
+If an issue is identified with the released source code on the supported
+kernel with a supported adapter, email the specific information related
+to the issue to e1000-devel@lists.sf.net
^ permalink raw reply related
* [PATCH 2/2] igbvf.txt: Add igbvf Documentation
From: Jeff Kirsher @ 2010-08-04 0:16 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, gospo, bphilips, Jeff Kirsher
In-Reply-To: <20100804001429.6571.95116.stgit@localhost.localdomain>
Adds documentation for the igbvf (igb virtual function driver).
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
---
Documentation/networking/igbvf.txt | 82 ++++++++++++++++++++++++++++++++++++
1 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 Documentation/networking/igbvf.txt
diff --git a/Documentation/networking/igbvf.txt b/Documentation/networking/igbvf.txt
new file mode 100644
index 0000000..06bf4bf
--- /dev/null
+++ b/Documentation/networking/igbvf.txt
@@ -0,0 +1,82 @@
+Linux* Base Driver for Intel(R) Network Connection
+==================================================
+
+Intel Gigabit Linux driver.
+Copyright(c) 1999 - 2010 Intel Corporation.
+
+Contents
+========
+
+- Identifying Your Adapter
+- Additional Configurations
+- Support
+
+This file describes the igbvf Linux* Base Driver for Intel Network Connection.
+
+The igbvf driver supports 82576-based virtual function devices that can only
+be activated on kernels that support SR-IOV. SR-IOV requires the correct
+platform and OS support.
+
+The igbvf driver requires the igb driver, version 2.0 or later. The igbvf
+driver supports virtual functions generated by the igb driver with a max_vfs
+value of 1 or greater. For more information on the max_vfs parameter refer
+to the README included with the igb driver.
+
+The guest OS loading the igbvf driver must support MSI-X interrupts.
+
+This driver is only supported as a loadable module at this time. Intel is
+not supplying patches against the kernel source to allow for static linking
+of the driver. For questions related to hardware requirements, refer to the
+documentation supplied with your Intel Gigabit adapter. All hardware
+requirements listed apply to use with Linux.
+
+Instructions on updating ethtool can be found in the section "Additional
+Configurations" later in this document.
+
+VLANs: There is a limit of a total of 32 shared VLANs to 1 or more VFs.
+
+Identifying Your Adapter
+========================
+
+The igbvf driver supports 82576-based virtual function devices that can only
+be activated on kernels that support SR-IOV.
+
+For more information on how to identify your adapter, go to the Adapter &
+Driver ID Guide at:
+
+ http://support.intel.com/support/go/network/adapter/idguide.htm
+
+For the latest Intel network drivers for Linux, refer to the following
+website. In the search field, enter your adapter name or type, or use the
+networking link on the left to search for your adapter:
+
+ http://downloadcenter.intel.com/scripts-df-external/Support_Intel.aspx
+
+Additional Configurations
+=========================
+
+ 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.
+
+Support
+=======
+
+For general information, go to the Intel support website at:
+
+ http://support.intel.com
+
+or the Intel Wired Networking project hosted by Sourceforge at:
+
+ http://sourceforge.net/projects/e1000
+
+If an issue is identified with the released source code on the supported
+kernel with a supported adapter, email the specific information related
+to the issue to e1000-devel@lists.sf.net
+
+
^ permalink raw reply related
* Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Patrick Pannuto @ 2010-08-04 0:17 UTC (permalink / raw)
To: Greg KH
Cc: Patrick Pannuto, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-omap@vger.kernel.org,
damm@opensource.se, lethal@linux-sh.org, rjw@sisk.pl,
dtor@mail.ru, eric.y.miao@gmail.com, netdev@vger.kernel.org
In-Reply-To: <20100804000945.GA19729@suse.de>
>>>>
>>>> struct platform_device sub_bus1 = {
>>>> .name = "sub_bus1",
>>>> .id = -1,
>>>> .dev.bus = &my_bus_type,
>>>> }
>>>> EXPORT_SYMBOL_GPL(sub_bus1);
>>>
>>> You really want a bus hanging off of a bus? Normally you need a device
>>> to do that, which is what I think you have here, but the naming is a bit
>>> odd to me.
>>>
>>> What would you do with this "sub bus"? It's just a device, but you are
>>> wanting it to be around for something.
>>>
>>
>> It's for power management stuff, basically, there are actual physical buses
>> involved that can be completely powered off IFF all of their devices are
>> not in use. Plus it actually matches bus topology this way.
>
> Then create a real bus hanging off of a device, not another device that
> "acts" like a bus here, right? Or am I missing the point?
>
The motivation for doing it this was is that one driver could drive
devices on two different subbusses. In the example, "my-driver" could
drive a device on sub_bus1 AND sub_bus2 (if there were 2+ devices, one
or more on each bus).
>From my understanding, this is not possible if they are actually
different busses.
^ permalink raw reply
* can TCP socket send buffer be over used?
From: Jack Zhang @ 2010-08-04 0:22 UTC (permalink / raw)
To: netdev
Hi there,
I'm doing experiments with (modified*) software iSCSI over a link with
an emulated Round-Trip Time (RTT) of 100 ms by netem.
For example, when I set the send buffer size to 128 KB, i could get a
throughput up to 43 Mbps, which seems to be impossible as the (buffer
size) / RTT is only 10 Mbps.
And When I set the send buffer size to 512 KB, i can get a throughput
up to 60 Mbps, which also seems to be impossible as the (buffer size)
/ RTT is only 40 Mbps.
I understand that when the buffer size is set to 128 KB, I actually
got a buffer of 256 KB as the kernel doubles the buffer size. I also
understand that half the doubled buffer size is used for meta data
instead of the actual data to be transferred. So basically the
effective buffer sizes for the two examples are just 128 KB and 512
KB respectively.
So I was confused because, theoretically, send buffers of 128 KB and
512 KB should achieve no more than 10 Mbps and 40 Mbps respectively
but I was able to get way much more than the theoretical limit. So
I was wondering is there any chance the send buffer can be "overused"?
or there is some other mechanism inside TCP is doing some
optimization?
* the modification is to disable "TCP_NODELAY" , enable
"use_clustering" for SCSI, and set different send buffer sizes for the
TCP socket buffer.
Any idea will be highly appreciated.
Thanks a lot!
^ permalink raw reply
* Re: can TCP socket send buffer be over used?
From: Rick Jones @ 2010-08-04 0:30 UTC (permalink / raw)
To: Jack Zhang; +Cc: netdev
In-Reply-To: <AANLkTi=Ma2yMVbgRnUUB6T1j=rHLb60oAXqCSbM35KgT@mail.gmail.com>
Jack Zhang wrote:
> I understand that when the buffer size is set to 128 KB, I actually
> got a buffer of 256 KB as the kernel doubles the buffer size. I also
> understand that half the doubled buffer size is used for meta data
> instead of the actual data to be transferred. So basically the
> effective buffer sizes for the two examples are just 128 KB and 512
> KB respectively.
It may not be strictly 1/2. One way to check would be to take a tcpdump trace
on the sending side, and either work-out manually the most the connection has
outstanding at a time, or run the binary trace through something like tcptrace.
rick jones
^ permalink raw reply
* Re: [PATCH 1/2] igb.txt: Add igb documentation
From: Joe Perches @ 2010-08-04 0:39 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, linux-kernel, gospo, bphilips
In-Reply-To: <20100804001429.6571.95116.stgit@localhost.localdomain>
On Tue, 2010-08-03 at 17:15 -0700, Jeff Kirsher wrote:
> Add documentation for the igb networking driver.
It'd be nice if you could scare up
register level ipw-2xxx docs.
^ permalink raw reply
* Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Timothy Meade @ 2010-08-04 0:41 UTC (permalink / raw)
To: Patrick Pannuto
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-omap@vger.kernel.org, damm@opensource.se,
lethal@linux-sh.org, rjw@sisk.pl, dtor@mail.ru,
eric.y.miao@gmail.com, netdev@vger.kernel.org
In-Reply-To: <4C58B1B6.9050005@quicinc.com>
On Tue, Aug 3, 2010 at 8:17 PM, Patrick Pannuto <ppannuto@quicinc.com> wrote:
>>>>>
>>>>> struct platform_device sub_bus1 = {
>>>>> .name = "sub_bus1",
>>>>> .id = -1,
>>>>> .dev.bus = &my_bus_type,
>>>>> }
>>>>> EXPORT_SYMBOL_GPL(sub_bus1);
>>>>
>>>> You really want a bus hanging off of a bus? Normally you need a device
>>>> to do that, which is what I think you have here, but the naming is a bit
>>>> odd to me.
>>>>
>>>> What would you do with this "sub bus"? It's just a device, but you are
>>>> wanting it to be around for something.
>>>>
>>>
>>> It's for power management stuff, basically, there are actual physical buses
>>> involved that can be completely powered off IFF all of their devices are
>>> not in use. Plus it actually matches bus topology this way.
>>
>> Then create a real bus hanging off of a device, not another device that
>> "acts" like a bus here, right? Or am I missing the point?
>>
>
> The motivation for doing it this was is that one driver could drive
> devices on two different subbusses. In the example, "my-driver" could
> drive a device on sub_bus1 AND sub_bus2 (if there were 2+ devices, one
> or more on each bus).
>
> From my understanding, this is not possible if they are actually
> different busses.
This could be quite useful on the Qualcomm devices where there are
many collections of "devices" that resemble a bus but cannot be
directly enumerated but are initialized by platform code or possibly
in future, a device tree. One such bus is made up of SMI devices that
are identified to the applications core by the modem firmware and can
be in the form of character devices (smd), network devices (rmnet) rpc
router channel and others, we also have to deal with the MDDI video
bus which represented a challenge when migrating the HTC Rhodium to
2.6.32 as each mdp device (and others in later kernels) are added to
the platform bus dynamically, though they don't appear similararly
group in sysfs due to not actaully being on a bus. While it would
have been possible to implement an mddi bus, the work would have
essentially recreated the platform bus with a new name. A simliar
challenge exists for exposing rpc endpoints to userspace as the
current codebase uses character devices rather than introducing a new
network protocol to the kernel, if such as bus was exposed through
sysfs a userspace daemon could easily bind a GPS library to the PDAPI
endpoint or similar features requiring less configuration to adapt to
new AMSS firmware or device name layout.
Thank you,
Timothy Meade
tmzt #htc-linux
facebook.com/HTCLinux
^ permalink raw reply
* Re: [PATCH 1/2] igb.txt: Add igb documentation
From: Jeff Kirsher @ 2010-08-04 0:43 UTC (permalink / raw)
To: Joe Perches; +Cc: davem, netdev, linux-kernel, gospo, bphilips
In-Reply-To: <1280882391.1005.13.camel@Joe-Laptop.home>
On Tue, Aug 3, 2010 at 17:39, Joe Perches <joe@perches.com> wrote:
> On Tue, 2010-08-03 at 17:15 -0700, Jeff Kirsher wrote:
>> Add documentation for the igb networking driver.
>
> It'd be nice if you could scare up
> register level ipw-2xxx docs.
>
>
> --
That would be wireless, and I am with Wired LAN. Although Joe, I will
see what I can come up with, but I cannot promise anything... :)
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH 1/8] netdev: separate out davinci mdio controller code
From: Cyril Chemparathy @ 2010-08-04 0:44 UTC (permalink / raw)
To: Ramirez Luna, Omar
Cc: netdev@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com,
linux-omap@vger.kernel.org, Nori, Sekhar,
Govindarajan, Sriramakrishnan
In-Reply-To: <27F9C60D11D683428E133F85D2BB4A53043F3C8C2A@dlee03.ent.ti.com>
Hi Omar,
[...]
>> + while ((reg = __raw_readl(®s->user[0].access)) & USERACCESS_GO)
>> + ;
>
> potential infinite loop? I saw another place in your series using time_after, might fit in here too.
[...]
>> + while ((__raw_readl(®s->control) & CONTROL_IDLE) == 0)
>> + ;
>
> Ditto
Thanks. Will modify.
Regards
Cyril.
^ permalink raw reply
* Re: [PATCH 6/8] netdev: separate out davinci cpdma controller code
From: Cyril Chemparathy @ 2010-08-04 0:46 UTC (permalink / raw)
To: Ramirez Luna, Omar
Cc: netdev@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com,
linux-omap@vger.kernel.org, Nori, Sekhar,
Govindarajan, Sriramakrishnan
In-Reply-To: <27F9C60D11D683428E133F85D2BB4A53043F3C8C2B@dlee03.ent.ti.com>
Hi Omar,
[...]
>> + if (ctlr->channels[chan_num])
>> + goto err_chan_busy;
>
> Mem leaking 'chan'
>
Thanks. Will modify for v2.
Regards
Cyril.
^ permalink raw reply
* Re: can TCP socket send buffer be over used?
From: Jack Zhang @ 2010-08-04 0:48 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4C58B4B4.6010904@hp.com>
Hi Rick,
Thanks for your reply.
Do you maybe know which part of the source code implements the details
about how much send buffer can actually be used for the data payload?
Thanks a lot!
Jack
On 3 August 2010 18:30, Rick Jones <rick.jones2@hp.com> wrote:
> Jack Zhang wrote:
>>
>> I understand that when the buffer size is set to 128 KB, I actually
>> got a buffer of 256 KB as the kernel doubles the buffer size. I also
>> understand that half the doubled buffer size is used for meta data
>> instead of the actual data to be transferred. So basically the
>> effective buffer sizes for the two examples are just 128 KB and 512
>> KB respectively.
>
> It may not be strictly 1/2. One way to check would be to take a tcpdump
> trace on the sending side, and either work-out manually the most the
> connection has outstanding at a time, or run the binary trace through
> something like tcptrace.
>
> rick jones
>
^ permalink raw reply
* Re: [GIT PULL] xen-netfront driver updates for 2.6.36
From: Jeremy Fitzhardinge @ 2010-08-04 0:49 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, Xen-devel, dongxiao.xu
In-Reply-To: <20100803.163700.71134702.davem@davemloft.net>
On 08/03/2010 04:37 PM, David Miller wrote:
> From: Jeremy Fitzhardinge<jeremy@goop.org>
> Date: Tue, 03 Aug 2010 11:39:45 -0700
>
>> Here's a git branch with some updates to the Xen netfront driver,
>> which add a new "smartpoll" mode to the netfront backend protocol,
>> which is basically equivalent to interrupt mitigation. This merges
>> cleanly with current linux-next (it previously just had a small
>> constification conflict).
>>
>> Do you want to take this via the net tree, or are you OK with me
>> submitting them directly?
> Well from my perspective:
>
> 1) It's too late to put into my tree because the merge window has
> already started. If you want me to include this you should have
> asked me to pull it in days if not weeks ago.
OK, there's no particular rush.
> 2) Your tree is absolutely not in a state I can pull it. It has lots
> of completely unrelated commits which are not in net-next-2.6 which
> in no way should I be pulling into my tree.
It's based on v2.6.35. I can rebase to net-next-2.6.
> When you want me to take changes, your tree should be based upon mine.
> And when I pull from your tree I should get only your specific
> xen-netfront driver changes, and nothing more.
Sure.
Thanks,
J
^ permalink raw reply
* [PATCH v2] phy/marvell: add 88ec048 support
From: Cyril Chemparathy @ 2010-08-04 0:59 UTC (permalink / raw)
To: netdev; +Cc: Cyril Chemparathy
Marvell 88ec048 is a derivative of its 88e1121r device. From the programmer's
perspective, the one major difference is the addition of an additional control
bit in Page 2 Register 16 - used to control the padding of odd nibble
preambles.
This patch adds support for this new device, while inheriting as much code as
possible from the existing 88e1121r implementation.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
---
Changes from v1:
- added marvell_tbl entry for 88ec048
drivers/net/phy/marvell.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index b1413ae..721a090 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -75,6 +75,9 @@
#define MII_88E1121_PHY_MSCR_TX_DELAY BIT(4)
#define MII_88E1121_PHY_MSCR_DELAY_MASK (~(0x3 << 4))
+#define MII_88EC048_PHY_MSCR1_REG 16
+#define MII_88EC048_PHY_MSCR1_PAD_ODD BIT(6)
+
#define MII_88E1121_PHY_LED_CTRL 16
#define MII_88E1121_PHY_LED_PAGE 3
#define MII_88E1121_PHY_LED_DEF 0x0030
@@ -231,6 +234,31 @@ static int m88e1121_config_aneg(struct phy_device *phydev)
return err;
}
+static int m88ec048_config_aneg(struct phy_device *phydev)
+{
+ int err, oldpage, mscr;
+
+ oldpage = phy_read(phydev, MII_88E1121_PHY_PAGE);
+
+ err = phy_write(phydev, MII_88E1121_PHY_PAGE,
+ MII_88E1121_PHY_MSCR_PAGE);
+ if (err < 0)
+ return err;
+
+ mscr = phy_read(phydev, MII_88EC048_PHY_MSCR1_REG);
+ mscr |= MII_88EC048_PHY_MSCR1_PAD_ODD;
+
+ err = phy_write(phydev, MII_88E1121_PHY_MSCR_REG, mscr);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, MII_88E1121_PHY_PAGE, oldpage);
+ if (err < 0)
+ return err;
+
+ return m88e1121_config_aneg(phydev);
+}
+
static int m88e1111_config_init(struct phy_device *phydev)
{
int err;
@@ -622,6 +650,19 @@ static struct phy_driver marvell_drivers[] = {
.driver = { .owner = THIS_MODULE },
},
{
+ .phy_id = 0x01410e90,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Marvell 88EC048",
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_aneg = &m88ec048_config_aneg,
+ .read_status = &marvell_read_status,
+ .ack_interrupt = &marvell_ack_interrupt,
+ .config_intr = &marvell_config_intr,
+ .did_interrupt = &m88e1121_did_interrupt,
+ .driver = { .owner = THIS_MODULE },
+ },
+ {
.phy_id = 0x01410cd0,
.phy_id_mask = 0xfffffff0,
.name = "Marvell 88E1145",
@@ -686,6 +727,7 @@ static struct mdio_device_id marvell_tbl[] = {
{ 0x01410cb0, 0xfffffff0 },
{ 0x01410cd0, 0xfffffff0 },
{ 0x01410e30, 0xfffffff0 },
+ { 0x01410e90, 0xfffffff0 },
{ }
};
--
1.7.0.4
^ permalink raw reply related
* Re: can TCP socket send buffer be over used?
From: Rick Jones @ 2010-08-04 1:17 UTC (permalink / raw)
To: Jack Zhang; +Cc: netdev
In-Reply-To: <AANLkTikqTHNmTQL2-QSJZmJ=18CfdZGo41zUE6mKO_PS@mail.gmail.com>
Jack Zhang wrote:
> Hi Rick,
>
> Thanks for your reply.
>
> Do you maybe know which part of the source code implements the details
> about how much send buffer can actually be used for the data payload?
Specifically no. I've not had to go looking for it.
happy benchmarking,
rick jones
^ permalink raw reply
* RE: [RFC PATCH v8 00/16] Provide a zero-copy method on KVM virtio-net.
From: Dong, Eddie @ 2010-08-04 2:06 UTC (permalink / raw)
To: Arnd Bergmann, Shirley Ma
Cc: Xin, Xiaohui, netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mst@redhat.com, mingo@elte.hu,
davem@davemloft.net, herbert@gondor.apana.org.au,
jdike@linux.intel.com, Dong, Eddie, Dong, Eddie
In-Reply-To: <201007311130.17000.arnd@arndb.de>
Arnd Bergmann wrote:
> On Friday 30 July 2010 17:51:52 Shirley Ma wrote:
>> On Fri, 2010-07-30 at 16:53 +0800, Xin, Xiaohui wrote:
>>>> Since vhost-net already supports macvtap/tun backends, do you think
>>>> whether it's better to implement zero copy in macvtap/tun than
>>>> inducing a new media passthrough device here?
>>>>
>>>
>>> I'm not sure if there will be more duplicated code in the kernel.
>>
>> I think it should be less duplicated code in the kernel if we use
>> macvtap to support what media passthrough driver here. Since macvtap
>> has support virtio_net head and offloading already, the only missing
>> func is zero copy. Also QEMU supports macvtap, we just need add a
>> zero copy flag in option.
>
> Yes, I fully agree and that was one of the intended directions for
> macvtap to start with. Thank you so much for following up on that,
> I've long been planning to work on macvtap zero-copy myself but it's
> now lower on my priorities, so it's good to hear that you made
> progress on it, even if there are still performance issues.
>
But zero-copy is a Linux generic feature that can be used by other VMMs as well if the BE service drivers want to incorporate. If we can make mp device VMM-agnostic (it may be not yet in current patch), that will help Linux more.
Thx, Eddie
^ permalink raw reply
* Re: [PATCH 1/2] igb.txt: Add igb documentation
From: Ben Hutchings @ 2010-08-04 2:34 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, linux-kernel, gospo, bphilips
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.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox