* Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
From: David Miller @ 2010-06-30 20:58 UTC (permalink / raw)
To: shemminger; +Cc: joakim.tjernlund, netdev
In-Reply-To: <20100630135535.0e3a5ea1@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 30 Jun 2010 13:55:35 -0700
>> The fact that the syctl knob, when enabled, can't even function properly
>> in this "multiple interfaces with same address" case is another reason I
>> have decided to not apply this.
>
> We already have sysctl knobs that exist to work around broken printer TCP,
> middleboxes and other broken stacks; my opinion this is just another one
> of those types of workarounds.
But that sysctl knob for the printer workaround doesn't break legitimate
configurations like this one does.
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Ben Hutchings @ 2010-06-30 21:03 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, jmatthews, Tim Heath, Herbert Xu
In-Reply-To: <AANLkTinJC6uS1GTbKJWL9AlEs2e5GleQvJbTUZrsQHaE@mail.gmail.com>
On Wed, 2010-06-30 at 11:04 -0700, Ivan Novick wrote:
> Hello all,
>
> Attached is a packet capture from my application that is running on
> RedHat Enterprise Linux 5.4
>
> I am seeing a Retransmission timeout but I was hoping this case would
> go into fast retransmit and not RTO.
>
> I am wondering why did the sender not send more data? If the sender
> was to send more data and extend the window then it would seem the
> duplicate acks or SACKS should trigger fast retransmit.
[...]
In that packet capture I see TCP payload lengths which are 2, 3 and 4
times the usual MSS of 1448 bytes, which implies that GRO or LRO is in
use. In RHEL 5.4 the TCP stack does not ACK often enough in this case
because it is missing this change:
commit ff9b5e0f08cb650d113eef0c654f931c0a7ae730
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Aug 31 15:11:02 2006 -0700
[TCP]: Fix rcv mss estimate for LRO
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
* Re: [PATCH 0/2] cxgb4vf: small fixes to new driver
From: David Miller @ 2010-06-30 21:05 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <201006291552.14816.leedom@chelsio.com>
I've applied both patches but you really need to fix up how you
submit these changes.
1) Your Subject: line becomes the commit message header.
It should be a single statement, prefixed by "xxx: "
where "xxx" is the subsystem or driver you are making
changes to. Here it would be "cxgb4vf: "
It should not bleed into the rest of commit message body, like
your's did.
2) You should not include all of the commit crap from GIT in the body
of your email. I just have to edit all of that junk out before I
apply your patch.
A perfect email patch submission looks like this (my comments are in
{} braces):
From: Me <me@wherever.com>
Subject: [PATCH N/M] subsystem: Make whatever do whatever.
{ Next line is optional, it goes into your email body and is used
when the patch author is someone other than the person sending
the email }
From: Real Author <cooldude@wherever.com>
This explains what this commit message is doing.
It gives code path traces, pretty ascii-art diagrams, and cross
references when doing so helps other people understand the change.
Signed-off-by: Real Author <cooldude@wherever.com>
Signed-off-by: Me <me@wherever.com>
{ "---" marks the end of the commit message text, afterwards you
can add whatever auxiliary information you want people to know about
the patch, but for whatever reason it'snt appropriate for the
commit message. }
---
This is some extra information I want the list to see when I post
this patch.
{ And finally the full patch comes next. }
Ok? All of the GIT tools know exactly how to pick apart the above
formatted patch and apply it to the tree with the author, etc. all
set properly.
And this is the format output by "git send-email" so you can use it
to help construct proper patch postings even if you don't want to
use "git send-email" to send the email directly.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/3] ethtool: Change ethtool_op_set_flags to validate flags
From: David Miller @ 2010-06-30 21:10 UTC (permalink / raw)
To: bhutchings
Cc: netdev, linux-net-drivers, sgruszka, amit.salecha, amwang,
anirban.chakraborty, dm, scofeldm, vkolluri, roprabhu,
e1000-devel, buytenh, gallatin, brice, shemminger, jgarzik
In-Reply-To: <1277901872.2082.10.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 30 Jun 2010 13:44:32 +0100
> ethtool_op_set_flags() does not check for unsupported flags, and has
> no way of doing so. This means it is not suitable for use as a
> default implementation of ethtool_ops::set_flags.
>
> Add a 'supported' parameter specifying the flags that the driver and
> hardware support, validate the requested flags against this, and
> change all current callers to pass this parameter.
>
> Change some other trivial implementations of ethtool_ops::set_flags to
> call ethtool_op_set_flags().
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/3] netdev: Make ethtool_ops::set_flags() return -EINVAL for unsupported flags
From: David Miller @ 2010-06-30 21:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev
In-Reply-To: <1277902016.2082.12.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 30 Jun 2010 13:46:56 +0100
> The documented error code for attempts to set unsupported flags (or
> to clear flags that cannot be disabled) is EINVAL, not EOPNOTSUPP.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 3/3] vmxnet3: Remove incorrect implementation of ethtool_ops::get_flags()
From: David Miller @ 2010-06-30 21:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, sbhatewara, pv-drivers
In-Reply-To: <1277902060.2082.13.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 30 Jun 2010 13:47:40 +0100
> Only some netdev feature flags correspond directly to ethtool feature
> flags. ethtool_op_get_flags() does the right thing.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] ethtool: Add support for control of RX flow hash indirection
From: David Miller @ 2010-06-30 21:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1277910323.2082.14.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 30 Jun 2010 16:05:23 +0100
> Many NICs use an indirection table to map an RX flow hash value to one
> of an arbitrary number of queues (not necessarily a power of 2). It
> can be useful to remove some queues from this indirection table so
> that they are only used for flows that are specifically filtered
> there. It may also be useful to weight the mapping to account for
> user processes with the same CPU-affinity as the RX interrupts.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Looks good, applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] sfc: Add support for RX flow hash control
From: David Miller @ 2010-06-30 21:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1277910388.2082.15.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 30 Jun 2010 16:06:28 +0100
> Allow ethtool to query the number of RX rings, the fields used in RX
> flow hashing and the hash indirection table.
>
> Allow ethtool to update the RX flow hash indirection table.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] cxgb4vf: small fixes to new driver
From: Casey Leedom @ 2010-06-30 21:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100630.140513.171484395.davem@davemloft.net>
| From: David Miller <davem@davemloft.net>
| Date: Wednesday, June 30, 2010 02:05 pm
|
| I've applied both patches but you really need to fix up how you
| submit these changes.
Thanks David. I won't submit any more patches till I get my local git patch
experts to vet the results. You shouldn't be asked to do such mechanical patch
fixups. I appreciate your time in describing this. Thanks!
Hoping not to be a Patch Bozo in future submissions,
Casey
P.S. Is the below in a FAQ and/or Wiki somewhere? if not, I think it would make
a valuable addition. (And if it already is in a FAQ/Wiki then I'm even more of
a Patch Bozo ...)
| 1) Your Subject: line becomes the commit message header.
|
| It should be a single statement, prefixed by "xxx: "
| where "xxx" is the subsystem or driver you are making
| changes to. Here it would be "cxgb4vf: "
|
| It should not bleed into the rest of commit message body, like
| your's did.
|
| 2) You should not include all of the commit crap from GIT in the body
| of your email. I just have to edit all of that junk out before I
| apply your patch.
|
| A perfect email patch submission looks like this (my comments are in
| {} braces):
|
| From: Me <me@wherever.com>
| Subject: [PATCH N/M] subsystem: Make whatever do whatever.
|
| { Next line is optional, it goes into your email body and is used
| when the patch author is someone other than the person sending
| the email }
|
| From: Real Author <cooldude@wherever.com>
|
| This explains what this commit message is doing.
|
| It gives code path traces, pretty ascii-art diagrams, and cross
| references when doing so helps other people understand the change.
|
| Signed-off-by: Real Author <cooldude@wherever.com>
| Signed-off-by: Me <me@wherever.com>
|
| { "---" marks the end of the commit message text, afterwards you
| can add whatever auxiliary information you want people to know about
| the patch, but for whatever reason it'snt appropriate for the
| commit message. }
|
| ---
|
| This is some extra information I want the list to see when I post
| this patch.
|
| { And finally the full patch comes next. }
|
| Ok? All of the GIT tools know exactly how to pick apart the above
| formatted patch and apply it to the tree with the author, etc. all
| set properly.
|
| And this is the format output by "git send-email" so you can use it
| to help construct proper patch postings even if you don't want to
| use "git send-email" to send the email directly.
^ permalink raw reply
* Re: [PATCH 0/2] cxgb4vf: small fixes to new driver
From: David Miller @ 2010-06-30 21:22 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <201006301413.42716.leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Wed, 30 Jun 2010 14:13:42 -0700
> P.S. Is the below in a FAQ and/or Wiki somewhere? if not, I think it would make
> a valuable addition. (And if it already is in a FAQ/Wiki then I'm even more of
> a Patch Bozo ...)
See the "DISCUSSION" section of "git help am"
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: David Miller @ 2010-06-30 21:22 UTC (permalink / raw)
To: bhutchings; +Cc: novickivan, netdev, jmatthews, theath, herbert
In-Reply-To: <1277931829.4878.9.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 30 Jun 2010 22:03:49 +0100
> In that packet capture I see TCP payload lengths which are 2, 3 and 4
> times the usual MSS of 1448 bytes, which implies that GRO or LRO is in
> use. In RHEL 5.4 the TCP stack does not ACK often enough in this case
> because it is missing this change:
>
> commit ff9b5e0f08cb650d113eef0c654f931c0a7ae730
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Thu Aug 31 15:11:02 2006 -0700
>
> [TCP]: Fix rcv mss estimate for LRO
It certainly could be, I'll try make sure this gets rectified,
thanks!
^ permalink raw reply
* Re: [PATCH] bridge: add per bridge device controls for invoking iptables
From: Stephen Hemminger @ 2010-06-30 21:24 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <1277729220-11775-1-git-send-email-kaber@trash.net>
On Mon, 28 Jun 2010 14:47:00 +0200
kaber@trash.net wrote:
> From: Patrick McHardy <kaber@trash.net>
>
> Support more fine grained control of bridge netfilter iptables invocation
> by adding seperate brnf_call_*tables parameters for each device using the
> sysfs interface. Packets are passed to layer 3 netfilter when either the
> global parameter or the per bridge parameter is enabled.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Looks like a good idea.
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
--
^ permalink raw reply
* Re: [PATCH] bridge: add per bridge device controls for invoking iptables
From: David Miller @ 2010-06-30 21:27 UTC (permalink / raw)
To: shemminger; +Cc: kaber, netdev
In-Reply-To: <20100630142440.68adfdb1@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 30 Jun 2010 14:24:40 -0700
> On Mon, 28 Jun 2010 14:47:00 +0200
> kaber@trash.net wrote:
>
>> From: Patrick McHardy <kaber@trash.net>
>>
>> Support more fine grained control of bridge netfilter iptables invocation
>> by adding seperate brnf_call_*tables parameters for each device using the
>> sysfs interface. Packets are passed to layer 3 netfilter when either the
>> global parameter or the per bridge parameter is enabled.
>>
>> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> Looks like a good idea.
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: David S. Miller <davem@davemloft.net>
Patrick since this is mostly netfilter'ish, please toss it into one
of your trees.
Thanks!
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: add 1g PHY support for 82599
From: David Miller @ 2010-06-30 21:27 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, donald.c.skidmore
In-Reply-To: <20100630043017.8987.49958.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:30:59 -0700
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> Add support for 1G SFP+ PHY's to 82599.
>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
From: David Miller @ 2010-06-30 21:28 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, tglx, mingo, hpa, x86, alexander.h.duyck
In-Reply-To: <20100630043728.9224.64191.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 29 Jun 2010 21:38:00 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> x86 architectures can handle unaligned accesses in hardware, and it has
> been shown that unaligned DMA accesses can be expensive on Nehalem
> architectures. As such we should overwrite NET_IP_ALIGN to resolve
> this issue.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Can I get an x86'er ACK on this? I can merge it in via net-next-2.6
which is probably most convenient for people who want to see the
networking performance effects of this change.
^ permalink raw reply
* Re: [PATCHv2] vhost-net: add dhclient work-around from userspace
From: David Miller @ 2010-06-30 21:30 UTC (permalink / raw)
To: mst
Cc: arozansk, herbert.xu, quintela, kvm, virtualization, netdev,
linux-kernel, ykaul, markmc
In-Reply-To: <20100629130439.GD3603@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 29 Jun 2010 16:04:39 +0300
> Since using the module involves updating the management tools
> as well, if we go down this route it will be much less painful
> for everyone to do push it upstream.
Ok, you can make your case to Patrick McHardy and if he'll merge
it into his netfilter GIT tree I guess I'll have to take it :)
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
From: H. Peter Anvin @ 2010-06-30 21:32 UTC (permalink / raw)
To: David Miller
Cc: jeffrey.t.kirsher, netdev, gospo, bphilips, tglx, mingo, x86,
alexander.h.duyck
In-Reply-To: <20100630.142832.51275605.davem@davemloft.net>
On 06/30/2010 02:28 PM, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Tue, 29 Jun 2010 21:38:00 -0700
>
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> x86 architectures can handle unaligned accesses in hardware, and it has
>> been shown that unaligned DMA accesses can be expensive on Nehalem
>> architectures. As such we should overwrite NET_IP_ALIGN to resolve
>> this issue.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Can I get an x86'er ACK on this? I can merge it in via net-next-2.6
> which is probably most convenient for people who want to see the
> networking performance effects of this change.
Acked-by: H. Peter Anvin <hpa@zytor.com>
-hpa
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
From: David Miller @ 2010-06-30 21:34 UTC (permalink / raw)
To: hpa
Cc: jeffrey.t.kirsher, netdev, gospo, bphilips, tglx, mingo, x86,
alexander.h.duyck
In-Reply-To: <4C2BB7F1.6050009@zytor.com>
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 30 Jun 2010 14:32:33 -0700
> On 06/30/2010 02:28 PM, David Miller wrote:
>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Tue, 29 Jun 2010 21:38:00 -0700
>>
>>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>>
>>> x86 architectures can handle unaligned accesses in hardware, and it has
>>> been shown that unaligned DMA accesses can be expensive on Nehalem
>>> architectures. As such we should overwrite NET_IP_ALIGN to resolve
>>> this issue.
>>>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>> Cc: x86@kernel.org
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>
>> Can I get an x86'er ACK on this? I can merge it in via net-next-2.6
>> which is probably most convenient for people who want to see the
>> networking performance effects of this change.
>
> Acked-by: H. Peter Anvin <hpa@zytor.com>
Applied, thanks everyone.
^ permalink raw reply
* [PATCH 1/1] ehea: Allocate stats buffer with GFP_KERNEL
From: Brian King @ 2010-06-30 21:59 UTC (permalink / raw)
To: ossthema; +Cc: osstklei, raisch, netdev, brking
Since ehea_get_stats calls ehea_h_query_ehea_port, which
can sleep, we can also sleep when allocating a page in
this function. This fixes some memory allocation failure
warnings seen under low memory conditions.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
drivers/net/ehea/ehea_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/ehea/ehea_main.c~ehea_get_stats_gfp drivers/net/ehea/ehea_main.c
--- linux-2.6/drivers/net/ehea/ehea_main.c~ehea_get_stats_gfp 2010-06-28 09:46:51.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ehea/ehea_main.c 2010-06-28 09:46:51.000000000 -0500
@@ -335,7 +335,7 @@ static struct net_device_stats *ehea_get
memset(stats, 0, sizeof(*stats));
- cb2 = (void *)get_zeroed_page(GFP_ATOMIC);
+ cb2 = (void *)get_zeroed_page(GFP_KERNEL);
if (!cb2) {
ehea_error("no mem for cb2");
goto out;
_
^ permalink raw reply
* Re: [PATCHv2] vhost-net: add dhclient work-around from userspace
From: Anthony Liguori @ 2010-06-30 22:08 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, arozansk, herbert.xu, quintela, kvm, virtualization,
netdev, linux-kernel, ykaul, markmc
In-Reply-To: <20100629130439.GD3603@redhat.com>
On 06/29/2010 08:04 AM, Michael S. Tsirkin wrote:
> On Tue, Jun 29, 2010 at 12:36:47AM -0700, David Miller wrote:
>
>> From: "Michael S. Tsirkin"<mst@redhat.com>
>> Date: Mon, 28 Jun 2010 13:08:07 +0300
>>
>>
>>> Userspace virtio server has the following hack
>>> so guests rely on it, and we have to replicate it, too:
>>>
>>> Use port number to detect incoming IPv4 DHCP response packets,
>>> and fill in the checksum for these.
>>>
>>> The issue we are solving is that on linux guests, some apps
>>> that use recvmsg with AF_PACKET sockets, don't know how to
>>> handle CHECKSUM_PARTIAL;
>>> The interface to return the relevant information was added
>>> in 8dc4194474159660d7f37c495e3fc3f10d0db8cc,
>>> and older userspace does not use it.
>>> One important user of recvmsg with AF_PACKET is dhclient,
>>> so we add a work-around just for DHCP.
>>>
>>> Don't bother applying the hack to IPv6 as userspace virtio does not
>>> have a work-around for that - let's hope guests will do the right
>>> thing wrt IPv6.
>>>
>>> Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
>>>
>> Yikes, this is awful too.
>>
>> Nothing in the kernel should be mucking around with procotol packets
>> like this by default. In particular, what the heck does port 67 mean?
>> Locally I can use it for whatever I want for my own purposes, I don't
>> have to follow the conventions for service ports as specified by the
>> IETF.
>>
>> But I can't have the packet checksum state be left alone for port 67
>> traffic on a box using virtio because you have this hack there.
>>
>> And yes it's broken on machines using the qemu thing, but at least the
>> hack there is restricted to userspace.
>>
> Yes, and I think it was a mistake to add the hack there. This is what
> prevented applications from using the new interface in the 3 years
> since it was first introduced.
>
It's far more complicated than that. dhclient is part of ISC's DHCP
package. They do not have a public SCM and instead require you to join
their Software Guild to get access to it.
This problem was identified in one distribution and the patch was pushed
upstream but because they did not have a public SCM, most other
distributions did not see the fix until it appeared in a release. ISC
has a pretty long release cycle historically.
ISC's had the fix for a long time but there was a 3-year gap in their
releases and since their SCM isn't public, users are stuck with the last
release.
This hack makes sense in QEMU as we have a few hacks like this to fix
broken guests. A primary use of virtualization is to run old
applications so it makes sense for us to do that.
I don't think it makes sense for vhost to do this. These guests are so
old that they don't have the requisite features to achieve really high
performance anyway.
I've always thought making vhost totally transparent was a bad idea and
this is one of the reasons. We can do a lot of ugly things in userspace
that we shouldn't be doing in the kernel.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: b44: Reset due to FIFO overflow.
From: James Courtier-Dutton @ 2010-06-30 22:20 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, erblichs, netdev
In-Reply-To: <20100630.132220.129754921.davem@davemloft.net>
On 30 June 2010 21:22, David Miller <davem@davemloft.net> wrote:
> From: James Courtier-Dutton <james.dutton@gmail.com>
> Date: Mon, 28 Jun 2010 11:17:59 +0100
>
>> Interesting, which hardware, apart from the b44, is it that "requires"
>> a hardware reset after a RX FIFO overflow.
>
> This problem is quite common, actually.
>
> Even though it shouldn't be, this is seemingly one of the least tested
> paths of a networking chip.
>
> You'd think the recovery would be easy, flush the fifos and drop the
> packet, then rewind the RX descriptor pointer.
>
> But it's not and I've seen everything from RX descriptor corruption
> to random DMA splats elsewhere corrupting memory entirely, as a result
> of a networking card taking a RX fifo overflow.
>
Well, I have just written a patch (see other thread) to try and reset
the FIFO instead of a complete HW reset.
How do I know if I have RX descriptor corruption, or random DMA splats?
I have not detected any problems so far.
^ permalink raw reply
* Re: [PATCHv2] vhost-net: add dhclient work-around from userspace
From: Michael S. Tsirkin @ 2010-06-30 22:31 UTC (permalink / raw)
To: Anthony Liguori
Cc: David Miller, arozansk, herbert.xu, quintela, kvm, virtualization,
netdev, linux-kernel, ykaul, markmc
In-Reply-To: <4C2BC04B.3000100@codemonkey.ws>
On Wed, Jun 30, 2010 at 05:08:11PM -0500, Anthony Liguori wrote:
> On 06/29/2010 08:04 AM, Michael S. Tsirkin wrote:
> >On Tue, Jun 29, 2010 at 12:36:47AM -0700, David Miller wrote:
> >>From: "Michael S. Tsirkin"<mst@redhat.com>
> >>Date: Mon, 28 Jun 2010 13:08:07 +0300
> >>
> >>>Userspace virtio server has the following hack
> >>>so guests rely on it, and we have to replicate it, too:
> >>>
> >>>Use port number to detect incoming IPv4 DHCP response packets,
> >>>and fill in the checksum for these.
> >>>
> >>>The issue we are solving is that on linux guests, some apps
> >>>that use recvmsg with AF_PACKET sockets, don't know how to
> >>>handle CHECKSUM_PARTIAL;
> >>>The interface to return the relevant information was added
> >>>in 8dc4194474159660d7f37c495e3fc3f10d0db8cc,
> >>>and older userspace does not use it.
> >>>One important user of recvmsg with AF_PACKET is dhclient,
> >>>so we add a work-around just for DHCP.
> >>>
> >>>Don't bother applying the hack to IPv6 as userspace virtio does not
> >>>have a work-around for that - let's hope guests will do the right
> >>>thing wrt IPv6.
> >>>
> >>>Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
> >>Yikes, this is awful too.
> >>
> >>Nothing in the kernel should be mucking around with procotol packets
> >>like this by default. In particular, what the heck does port 67 mean?
> >>Locally I can use it for whatever I want for my own purposes, I don't
> >>have to follow the conventions for service ports as specified by the
> >>IETF.
> >>
> >>But I can't have the packet checksum state be left alone for port 67
> >>traffic on a box using virtio because you have this hack there.
> >>
> >>And yes it's broken on machines using the qemu thing, but at least the
> >>hack there is restricted to userspace.
> >Yes, and I think it was a mistake to add the hack there. This is what
> >prevented applications from using the new interface in the 3 years
> >since it was first introduced.
>
> It's far more complicated than that. dhclient is part of ISC's DHCP
> package. They do not have a public SCM and instead require you to
> join their Software Guild to get access to it.
>
> This problem was identified in one distribution and the patch was
> pushed upstream but because they did not have a public SCM, most
> other distributions did not see the fix until it appeared in a
> release. ISC has a pretty long release cycle historically.
>
> ISC's had the fix for a long time but there was a 3-year gap in
> their releases and since their SCM isn't public, users are stuck
> with the last release.
>
> This hack makes sense in QEMU as we have a few hacks like this to
> fix broken guests.
> A primary use of virtualization is to run old
> applications so it makes sense for us to do that.
IMO it was wrong to put it in qemu: originally, if a distro shipped
a broken virtio/dhclient combo, it was it's own bug to fix.
But now that qemu has shipped the work-around for so long,
broken guests seemed work. So we *still* see the bug re-surface in new guests.
And since they are fairly new, it is interesting to
get decent performance from them now.
>
> I don't think it makes sense for vhost to do this. These guests are
> so old that they don't have the requisite features to achieve really
> high performance anyway.
>
> I've always thought making vhost totally transparent was a bad idea
> and this is one of the reasons.
It does not have to be fully transparent. You can insert your own ring
in the middle, and copy descriptors around. And we stop on errors and
let userspace handle. This will come handy if we get e.g. virtio bug
that we need to work around.
> We can do a lot of ugly things in
> userspace that we shouldn't be doing in the kernel.
>
> Regards,
>
> Anthony Liguori
QEMU is only userspace for the host. It is the hardware for the guest.
So IMO we should not be doing the ugly things there either.
--
MST
^ permalink raw reply
* RE: [net-next-2.6 PATCH 1/8] e1000e: cleanup ethtool loopback setup code
From: Allan, Bruce W @ 2010-06-30 22:41 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100618.221512.102550313.davem@davemloft.net>
On Friday, June 18, 2010 10:15 PM, David Miller wrote:
> I've applied this series however:
>
> 1) Please address Ben's concerns about turning EEE on by default
> given that standardization is not complete yet.
>
> 2) I hate module parameters, I'd rather you create a new ethtool
> feature bit and thus allow the setting to be modified at run
> time. Please create a new ethtool control flag, and remove
> this module option.
>
> Thanks.
Hi Dave,
I've been looking into your request number 2 above (as a reminder, it had to do with a patch I submitted that added a module parameter to e1000e in order to enable/disable Energy Efficient Ethernet for a particular type of adapter).
For this new ethtool feature bit/flag for EEE, would you prefer it be set via:
1) the generic parameter setting option (e.g. -s ethX [eee on|off]),
2) yet another new show/change option pair, or
3) a new option that can set this new feature and be expandable to future features that are likewise not related to existing ethtool options (e.g. -F [eee on|off] [whizbang on|off])?
For #2 or #3, it makes sense to use ethtool_op_[g|s]et_flags with new ETH_FLAG_<feature> and NETIF_F_<feature> defines, but #1 can be implemented that way or by using remaining reserved elements of struct ethtool_cmd - if your preference is for #1, would you prefer it be implemented with the former or latter?
Thanks,
Bruce.
^ permalink raw reply
* RE: [REGRESSION] e1000e stopped working
From: Maxim Levitsky @ 2010-06-30 22:59 UTC (permalink / raw)
To: Tantilov, Emil S
Cc: netdev@vger.kernel.org, Allan, Bruce W, Pieper, Jeffrey E
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FF4705C9D@rrsmsx501.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3835 bytes --]
On Tue, 2010-06-29 at 12:37 -0600, Tantilov, Emil S wrote:
> Maxim Levitsky wrote:
> > On Mon, 2010-06-28 at 18:09 -0700, Allan, Bruce W wrote:
> >> On Monday, June 28, 2010 10:14 AM, Maxim Levitsky wrote:
> >>> On Mon, 2010-06-28 at 10:04 -0700, Allan, Bruce W wrote:
> >>>> On Sunday, June 27, 2010 10:47 AM, Maxim Levitsky wrote:
> >>>>> On Sun, 2010-06-27 at 20:43 +0300, Maxim Levitsky wrote:
> >>>>>> On Sun, 2010-06-27 at 20:29 +0300, Maxim Levitsky wrote:
> >>>>>>> On Sun, 2010-06-27 at 20:27 +0300, Maxim Levitsky wrote:
> >>>>>>>> Just that,
> >>>>>>>>
> >>>>>>>> It doesn't receive anything from my internet router during
> >>>>>>>> DHCP.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DC
> >>>>>>>> Gigabit Network Connection [8086:104b] (rev 02) Subsystem:
> >>>>>>>> Intel Corporation Device [8086:0001] Control: I/O+ Mem+
> >>>>>>>> BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
> >>>>>>>> SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B-
> >>>>>>>> ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> >>>>>>>> INTx- Latency: 0 Interrupt: pin A routed to IRQ 47 Region 0:
> >>>>>>>> Memory at 50300000 (32-bit, non-prefetchable) [size=128K]
> >>>>>>>> Region 1: Memory at 50324000 (32-bit, non-prefetchable)
> >>>>>>>> [size=4K] Region 2: I/O ports at 30e0 [size=32]
> >>>>>>>> Capabilities: [c8] Power Management version 2 Flags: PMEClk-
> >>>>>>>> DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> >>>>>>>> Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities:
> >>>>>>>> [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
> >>>>>>>> Enable+ Address: 00000000fee0100c Data: 41c9 Kernel driver
> >>>>>>>> in use: e1000e Kernel modules: e1000e
> >>>>>>>>
> >>>>>>>> I use vanilla tree, commit
> >>>>>>>> bf2937695fe2330bfd8933a2310e7bdd2581dc2e
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>> Maxim Levitsky
> >>>>>>>>
> >>>>>>>
> >>>>>>> It appears to work now after reboot.
> >>>>>>> Will keep a look for this.
> >>>>>>>
> >>>>>>> Disregard for now.
> >>>>>>
> >>>>>>
> >>>>>> Just s2ram cycle, problem is back.
> >>>>>> Did full reboot (power off then on), same thing card doesn't
> >>>>>> work...
> >>>>>>
> >>>>>
> >>>>> Yep, s2ram sometimes 'fixes', sometimes breaks the card.
> >>>>> Something got broken in device initialization path.
> >>>>>
> >>>>> Best regards,
> >>>>> Maxim Levitsky
> >>>>
> >>>> What distro are you using? If RedHat, since you are using DHCP
> >>>> will you please try putting a "LINKDELAY=10" in the
> >>>> /etc/sysconfig/network-scripts/ifcfg-ethX config file.
> >>>>
> >>> I use ubuntu 9.10
> >>>
> >>>> Is there anything in the system log that might help narrow down the
> >>>> issue?
> >>>
> >>> Nothing, really nothing.
> >>> It seems to detect link, dhcp client sends requests, but doesn't
> >>> recieve a thing (even tried promisc mode - doesn't help)
> >>>
> >>>
> >>>
> >>> Best regards,
> >>> Maxim Levitsky
> >>
> >> Since you say this is a regression, when did this last work for you
> >> without this problem, i.e. which distro, which kernel?
> >
> > I always compile kernel, and last kernel I compiled here was vanilla
> > 2.6.33-rc4.
> > It works just fine.
> >
> > I mostly use my laptop, and therefore didn't update kernel on my
> > desktop for long time.
> >
> > If I find some free time I try to bisect the problem.
>
> Could you provide some additional info about your setup:
> ethtool -e eth0
> ethtool -d eth0
> kernel config (if possible)
>
> What is the model of your system/MB?
Sure,
My motherboard on this system is Intel DG965RY
The bug in about 90% reproducible.
Doing several s2ram cycles, its possible to catch a moment when the
device starts working.
Best regards,
Maxim Levitsky
[-- Attachment #2: eeprom --]
[-- Type: text/plain, Size: 14622 bytes --]
Offset Values
------ ------
0x0000 00 19 d1 ed 88 2a 00 08 ff ff 10 10 ff ff ff ff
0x0010 ff ff ff ff c7 10 01 00 86 80 4b 10 86 80 00 00
0x0020 01 0d 00 00 00 00 05 96 20 50 00 33 00 00 07 8d
0x0030 84 06 41 03 00 00 00 00 00 00 00 00 00 00 00 00
0x0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060 00 01 00 40 2a 12 07 40 ff ff ff ff ff ff ff ff
0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 1f ff
0x0080 20 61 1f 00 02 0e 12 00 40 2f 1f 00 18 90 1b 00
0x0090 00 00 12 00 a0 2f 1f 00 24 8b 11 00 f0 f8 12 00
0x00a0 00 20 1f 00 b0 10 10 00 00 00 11 00 c0 20 1f 00
0x00b0 9a 24 1d 00 d3 00 1e 00 a0 28 1f 00 ce 04 14 00
0x00c0 60 2f 1f 00 e4 29 10 00 00 00 1f 00 40 01 00 00
0x00d0 20 1f 1f 00 06 16 10 00 14 b8 11 00 2a 01 15 00
0x00e0 67 00 1e 00 40 1f 1f 00 65 00 14 00 2a 00 15 00
0x00f0 2a 00 16 00 60 1f 1f 00 b0 3f 12 00 ff c0 16 00
0x0100 ec 1d 17 00 ef f9 18 00 10 02 19 00 80 18 1f 00
0x0110 03 00 15 00 80 17 1f 00 08 00 16 00 80 17 1f 00
0x0120 08 d0 18 00 80 18 1f 00 18 d9 18 00 60 18 1f 00
0x0130 00 08 1a 00 00 00 1f 00 01 00 19 00 40 13 00 00
0x0140 51 60 1f 00 01 00 11 00 00 00 1f 00 ff ff ff ff
0x0150 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0160 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0170 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0180 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0190 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0210 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0220 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0230 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0240 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0250 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0260 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0270 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0280 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0290 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0300 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0310 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0320 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0330 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0340 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0350 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0360 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0370 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0380 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0390 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0400 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0410 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0420 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0430 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0440 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0450 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0460 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0470 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0480 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0490 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x04f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0500 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0510 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0520 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0530 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0540 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0550 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0560 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0570 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0580 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0590 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x05f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0600 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0610 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0620 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0630 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0640 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0650 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0660 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0670 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0680 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0690 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x06f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0700 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0710 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0720 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0730 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0740 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0750 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0760 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0770 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0780 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0790 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0800 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0810 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0820 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0830 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0840 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0850 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0860 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0870 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0880 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0890 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0900 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0910 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0920 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0930 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0940 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0950 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0960 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0970 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0980 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0990 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0aa0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ab0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ac0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ad0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ae0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0af0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ba0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0be0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bf0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ca0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ce0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cf0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0da0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0db0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0dc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0dd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0de0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0df0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ea0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0eb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ec0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ed0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ee0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ef0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fa0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ff0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[-- Attachment #3: misc --]
[-- Type: text/plain, Size: 1297 bytes --]
maxim@MAIN:~$ sudo ethtool -i eth1
driver: e1000e
version: 1.0.2-k4
firmware-version: 1.1-0
bus-info: 0000:00:19.0
maxim@MAIN:~$ sudo ethtool -g eth1
Ring parameters for eth1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
maxim@MAIN:~$ ifconfig
eth1 Link encap:Ethernet HWaddr 00:19:d1:ed:88:2a
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3411 (3.4 KB) TX bytes:2736 (2.7 KB)
Interrupt:20 Memory:50300000-50320000
Number of RX packets seems to increase
Wireshark doesn't see them
Example:
maxim@MAIN:~$ sudo dhclient eth1
Internet Systems Consortium DHCP Client V3.1.2
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth1/00:19:d1:ed:88:2a
Sending on LPF/eth1/00:19:d1:ed:88:2a
Sending on Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 18
[-- Attachment #4: reg_dump --]
[-- Type: audio/x-ape, Size: 2300 bytes --]
[-- Attachment #5: .config.gz --]
[-- Type: application/x-gzip, Size: 16213 bytes --]
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/8] e1000e: cleanup ethtool loopback setup code
From: David Miller @ 2010-06-30 23:06 UTC (permalink / raw)
To: bruce.w.allan; +Cc: jeffrey.t.kirsher, netdev
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A9001591F6130@orsmsx509.amr.corp.intel.com>
From: "Allan, Bruce W" <bruce.w.allan@intel.com>
Date: Wed, 30 Jun 2010 15:41:19 -0700
> I've been looking into your request number 2 above (as a reminder,
> it had to do with a patch I submitted that added a module parameter
> to e1000e in order to enable/disable Energy Efficient Ethernet for a
> particular type of adapter).
>
> For this new ethtool feature bit/flag for EEE, would you prefer it be set via:
> 1) the generic parameter setting option (e.g. -s ethX [eee on|off]),
> 2) yet another new show/change option pair, or
> 3) a new option that can set this new feature and be expandable to future features that are likewise not related to existing ethtool options (e.g. -F [eee on|off] [whizbang on|off])?
>
> For #2 or #3, it makes sense to use ethtool_op_[g|s]et_flags with
> new ETH_FLAG_<feature> and NETIF_F_<feature> defines, but #1 can be
> implemented that way or by using remaining reserved elements of
> struct ethtool_cmd - if your preference is for #1, would you prefer
> it be implemented with the former or latter?
I only have strong feelings about the kernel side, and an ETH_FLAG_* seems
best for this since other devices will have this feature too.
I don't think overloading parts of ethtool_cmd is wise.
^ 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