* [PATCH] Fix b44 RX FIFO overflow recovery.
From: James Courtier-Dutton @ 2010-06-30 20:11 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
Hi,
This patch improves the recovery after a RX FIFO overflow on the b44
Ethernet NIC.
Before it would do a complete chip reset, resulting is loss of link
for a few seconds.
This patch improves this to do recovery in about 20ms without loss of link.
Kind Regards
James
b44: Handle RX FIFO overflow better.
Signed off by: James@superbug.co.uk
[-- Attachment #2: b44-fix-rx-overflow.txt --]
[-- Type: text/plain, Size: 1363 bytes --]
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 69d9f3d..72537c1 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -852,12 +852,46 @@ static int b44_poll(struct napi_struct *napi, int budget)
/* spin_unlock(&bp->tx_lock); */
}
spin_unlock_irqrestore(&bp->lock, flags);
+ if (bp->istat & ISTAT_DSCE)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_DSCE\n");
+ }
+ if (bp->istat & ISTAT_DATAE)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_DATAE\n");
+ }
+ if (bp->istat & ISTAT_DPE)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_DPE\n");
+ }
+ if (bp->istat & ISTAT_RDU)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_RDU\n");
+ }
+ if (bp->istat & ISTAT_RFO)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_RFO\n");
+ spin_lock_irqsave(&bp->lock, flags);
+ b44_disable_ints(bp);
+ /* This resets the ISTAT_RFO flag */
+ ssb_device_enable(bp->sdev, 0);
+ b44_init_rings(bp);
+ b44_init_hw(bp, B44_FULL_RESET_SKIP_PHY);
+ netif_wake_queue(bp->dev);
+ spin_unlock_irqrestore(&bp->lock, flags);
+ work_done = 0;
+ }
+ if (bp->istat & ISTAT_TFU)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_TFU\n");
+ }
+
work_done = 0;
if (bp->istat & ISTAT_RX)
work_done += b44_rx(bp, budget);
- if (bp->istat & ISTAT_ERRORS) {
+ if ((bp->istat & ISTAT_ERRORS) && !(bp->istat & ISTAT_RFO)) {
spin_lock_irqsave(&bp->lock, flags);
b44_halt(bp);
b44_init_rings(bp);
^ permalink raw reply related
* Re: [patch] cpmac: use resource_size()
From: David Miller @ 2010-06-30 20:12 UTC (permalink / raw)
To: error27; +Cc: florian, jpirko, eric.dumazet, netdev, kernel-janitors
In-Reply-To: <20100628211933.GL19184@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Mon, 28 Jun 2010 23:19:33 +0200
> The original code is off by one because we should start counting at
> zero. So the size of the resource is end - start + 1. I switched it to
> use resource_size() to do the calculation.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied to net-next-2.6, thanks Dan.
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Ivan Novick @ 2010-06-30 20:14 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: netdev, jmatthews, Tim Heath
In-Reply-To: <9E73042B-BF54-48FD-8755-C215FD03C9AE@earthlink.net>
On Wed, Jun 30, 2010 at 1:06 PM, Mitchell Erblich
<erblichs@earthlink.net> wrote:
> On Jun 30, 2010, at 11:04 AM, Ivan Novick wrote:
... snip ...
> Sometimes, adding tracing within the tcps, can identify if.
> the tcp flow has periods of idleness,
> the tcp flow is/has been application limited versus network limited,
> whether the flow is in SS or CA?
> CA normally has DELayed ACks, which reduces the number
> of ACKs to 1/2 or more,
> Whether Fast re-xmit is triggered by 2 or 3 DupAcks.
> whether any burst avoidance has occured,
> etc,
Hi Mitchell,
When you say adding tracing within the tcps... what method are you
referring to, to add this tracing? Is it some tool or setting or are
you talking about adding custom debugging output to the kernel?
Cheers,
Ivan
^ permalink raw reply
* Re: [PATCH] vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
From: David Miller @ 2010-06-30 20:16 UTC (permalink / raw)
To: pedro.netdev; +Cc: netdev, kaber, bhutchings, eric.dumazet
In-Reply-To: <c38a6e1add643eb78bd0d28ee3984cf4@dondevamos.com>
From: Pedro Garcia <pedro.netdev@dondevamos.com>
Date: Mon, 28 Jun 2010 01:21:19 +0200
> Last version of the patch. Now I think it is OK, of course pending
> Eric's signed-off-by for the accel HW part.
Eric, please review.
>
> If this is too long for a changelog, tell me and I will try to sum it
> up:
To me, not commit message is too long, the more the better. :)
> + if ((event == NETDEV_UP) &&
> + (dev->features & NETIF_F_HW_VLAN_FILTER) &&
> + (dev->netdev_ops->ndo_vlan_rx_add_vid)) {
There is no reason to surround this final NULL pointer check with
parenthesis, it just makes reading it confusing.
> + if (vlan_dev)
> + skb->dev = vlan_dev;
> + else
> + if (vlan_id)
> + goto drop;
Please format this as:
if (a)
b;
else if (c)
d;
> + if (vlan_dev)
> + skb->dev = vlan_dev;
> + else
> + if (vlan_id)
> + goto drop;
Same here.
^ permalink raw reply
* Re: b44: Reset due to FIFO overflow.
From: David Miller @ 2010-06-30 20:22 UTC (permalink / raw)
To: james.dutton; +Cc: eric.dumazet, erblichs, netdev
In-Reply-To: <AANLkTimK4mGdsSq206aqfusXPvnQczbYDlOWSYXAbOQJ@mail.gmail.com>
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.
^ permalink raw reply
* Re: [PATCH] Fix b44 RX FIFO overflow recovery.
From: David Miller @ 2010-06-30 20:25 UTC (permalink / raw)
To: james.dutton; +Cc: netdev
In-Reply-To: <AANLkTik2BadzkkVcmlhgWh6rcLDm1kEu0RDqWuILnwVZ@mail.gmail.com>
From: James Courtier-Dutton <james.dutton@gmail.com>
Date: Wed, 30 Jun 2010 21:11:18 +0100
> diff --git a/drivers/net/b44.c b/drivers/net/b44.c
> index 69d9f3d..72537c1 100644
> --- a/drivers/net/b44.c
> +++ b/drivers/net/b44.c
> @@ -852,12 +852,46 @@ static int b44_poll(struct napi_struct *napi, int budget)
> /* spin_unlock(&bp->tx_lock); */
> }
> spin_unlock_irqrestore(&bp->lock, flags);
> + if (bp->istat & ISTAT_DSCE)
> + {
> + printk(KERN_INFO "b44_poll: ISTAT_DSCE\n");
> + }
Using braces here is overkill, and even if it was appropriate it's formatted
incorrectly, it should be:
if (x)
y;
for single-line code blocks, and:
if (x) {
y;
z;
}
For multi-line code blocks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] be2net: memory barrier fixes on IBM p7 platform
From: David Miller @ 2010-06-30 20:27 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100629101117.GA2338@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Tue, 29 Jun 2010 15:41:17 +0530
> The ibm p7 architecure seems to reorder memory accesses more
> aggressively than previous ppc64 architectures. This requires memory
> barriers to ensure that rx/tx doorbells are pressed only after
> memory to be DMAed is written.
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied, but I had to fix something:
> @@ -972,7 +976,8 @@ static struct be_eth_rx_compl *be_rx_compl_get(struct be_adapter *adapter)
>
> if (rxcp->dw[offsetof(struct amap_eth_rx_compl, valid) / 32] == 0)
> return NULL;
> -
> +
> + rmb();
That first addition does nothing but add erroneous trailing
whitespace.
You can physically see that something must be wrong here just by look
at this patch chunk, please review things more thoroughly before
submitting in the future.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] snmp: 64bit ipstats_mib for all arches
From: David Miller @ 2010-06-30 20:30 UTC (permalink / raw)
To: yoshfuji; +Cc: eric.dumazet, netdev
In-Reply-To: <4C2A0C22.4010202@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Wed, 30 Jun 2010 00:07:14 +0900
> Hello.
>
> Thank you for doing this work!
>
> Eric Dumazet wrote:
>> /proc/net/snmp and /proc/net/netstat expose SNMP counters.
>> Width of these counters is either 32 or 64 bits, depending on the size
>> of "unsigned long" in kernel.
>> This means user program parsing these files must already be prepared
>> to
>> deal with 64bit values, regardless of user program being 32 or 64 bit.
>
> Well, I'm rather not in favor of breaking user-space apps.
Eric has explained that applications must already be able to cope with
64-bit values here. I think this is a valid change to make and
telling users that non-broken (read as: 64-bit) stats are only
available via netlink is not a reasonable thing at all.
I'm going to apply Eric's patch.
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Mitchell Erblich @ 2010-06-30 20:43 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, jmatthews, Tim Heath
In-Reply-To: <AANLkTimpofANvn-sDZrE3kdq9owzYe8DJa8OfuVK04cM@mail.gmail.com>
On Jun 30, 2010, at 1:14 PM, Ivan Novick wrote:
> On Wed, Jun 30, 2010 at 1:06 PM, Mitchell Erblich
> <erblichs@earthlink.net> wrote:
>> On Jun 30, 2010, at 11:04 AM, Ivan Novick wrote:
> ... snip ...
>> Sometimes, adding tracing within the tcps, can identify if.
>> the tcp flow has periods of idleness,
>> the tcp flow is/has been application limited versus network limited,
>> whether the flow is in SS or CA?
>> CA normally has DELayed ACks, which reduces the number
>> of ACKs to 1/2 or more,
>> Whether Fast re-xmit is triggered by 2 or 3 DupAcks.
>> whether any burst avoidance has occured,
>> etc,
>
> Hi Mitchell,
>
> When you say adding tracing within the tcps... what method are you
> referring to, to add this tracing? Is it some tool or setting or are
> you talking about adding custom debugging output to the kernel?
>
> Cheers,
> Ivan
Ivan,
Custom debug code that was added into the fast-path
when extensive tcp flow analysis is desired.
Uses a runtime /proc var to not effect the fast-path
that by default is dis-abled.
Mitchell Erblich
^ permalink raw reply
* Re: [PATCH v3] fragment: add fast path for in-order fragments
From: David Miller @ 2010-06-30 20:44 UTC (permalink / raw)
To: xiaosuo
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, netdev,
erblichs
In-Reply-To: <1277822377-742-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 29 Jun 2010 22:39:37 +0800
> add fast path for in-order fragments
>
> As the fragments are sent in order in most of OSes, such as Windows, Darwin and
> FreeBSD, it is likely the new fragments are at the end of the inet_frag_queue.
> In the fast path, we check if the skb at the end of the inet_frag_queue is the
> prev we expect.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC] [PATCH] ethtool: Change ethtool_op_set_flags to validate flags
From: David Miller @ 2010-06-30 20:47 UTC (permalink / raw)
To: sgruszka; +Cc: bhutchings, amit.salecha, netdev, amwang, anirban.chakraborty
In-Reply-To: <20100630132111.72559f9f@dhcp-lab-109.englab.brq.redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Wed, 30 Jun 2010 13:21:11 +0200
> On Tue, 29 Jun 2010 17:01:01 +0100
> Ben Hutchings <bhutchings@solarflare.com> wrote:
>
>> This is the sort of change I'd like to see.
...
> Looks good for me as well.
>
> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Me too.
Ben, please submit this formally.
^ permalink raw reply
* Re: [PATCH v2] bonding: check if clients MAC addr has changed
From: David Miller @ 2010-06-30 20:52 UTC (permalink / raw)
To: fleitner; +Cc: bonding-devel, fubar, netdev, gospo
In-Reply-To: <1277835879-26834-1-git-send-email-fleitner@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Tue, 29 Jun 2010 15:24:39 -0300
> When two systems using bonding devices in adaptive load
> balancing (ALB) communicates with each other, an endless
> ping-pong of ARP replies starts between these two systems.
>
> What happens? In the ALB mode, bonding driver keeps track
> of each client connected in a hash table, so it can do the
> receive load balancing (RLB). This hash table is updated
> when an ARP reply is received, then it scans for the client
> entry, updates its MAC address and flag it to be announced
> later. Therefore, two seconds later, the alb monitor runs
> and send for each updated client entry two ARP replies
> updating this specific client. The same process happens on
> the receiving system, causing the endless ping-pong of arp
> replies.
>
> See more information including the relevant functions below:
...
> Signed-off-by: Flavio Leitner <fleitner@redhat.com>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied, thanks.
Probably one of the best networking commit log messages I've seen in a
long time. Nice work.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: sysctl to block responding on down interface
From: Stephen Hemminger @ 2010-06-30 20:55 UTC (permalink / raw)
To: David Miller; +Cc: joakim.tjernlund, netdev
In-Reply-To: <20100622.101537.245382806.davem@davemloft.net>
On Tue, 22 Jun 2010 10:15:37 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Fri, 11 Jun 2010 08:48:54 -0700
>
> > The initial problem report was for a management application that used ICMP
> > to check link availability.
>
> That application is buggy, and even if we apply this patch it will
> only properly function when speaking to systems in a non-default
> configuration. And, it would be a non-default setting which, by your
> own admission below, cannot function properly in valid interface
> configurations.
It is a remote management system not a local application.
The management system is stupid, but it is hard to argue with
customers that other system is broken.
> It's easier to fix the app to work in all cases than to add another
> sysctl knob hack for a segment of the world that can't seem to wrap
> their head around the fact that our behavior is valid, specified, and
> an explicit design decision meant to increase the chances of
> successful communication between two systems.
>
> > The default is disabled to maintain compatibility with previous behavior.
> > This is not recommended for server systems because it makes fail over more
> > difficult, and does not account for configurations where multiple interfaces
> > have the same IP address.
>
> 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.
^ permalink raw reply
* 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
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