* [PATCH 2/4] gro: Change all receive functions to return GRO result codes
From: Ben Hutchings @ 2009-10-29 17:18 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, netdev, linux-net-drivers
This will allow drivers to adjust their receive path dynamically
based on whether GRO is being applied successfully.
Currently all in-tree callers ignore the return values of these
functions and do not need to be changed.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/if_vlan.h | 25 ++++++++++++++-----------
include/linux/netdevice.h | 8 ++++----
net/8021q/vlan_core.c | 16 +++++++++-------
net/core/dev.c | 38 +++++++++++++++-----------------------
4 files changed, 42 insertions(+), 45 deletions(-)
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 7ff9af1..5be7680 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -115,10 +115,12 @@ extern u16 vlan_dev_vlan_id(const struct net_device *dev);
extern int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
u16 vlan_tci, int polling);
extern int vlan_hwaccel_do_receive(struct sk_buff *skb);
-extern int vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
- unsigned int vlan_tci, struct sk_buff *skb);
-extern int vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
- unsigned int vlan_tci);
+extern gro_result_t
+vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
+ unsigned int vlan_tci, struct sk_buff *skb);
+extern gro_result_t
+vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
+ unsigned int vlan_tci);
#else
static inline struct net_device *vlan_dev_real_dev(const struct net_device *dev)
@@ -145,17 +147,18 @@ static inline int vlan_hwaccel_do_receive(struct sk_buff *skb)
return 0;
}
-static inline int vlan_gro_receive(struct napi_struct *napi,
- struct vlan_group *grp,
- unsigned int vlan_tci, struct sk_buff *skb)
+static inline gro_result_t
+vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
+ unsigned int vlan_tci, struct sk_buff *skb)
{
- return NET_RX_DROP;
+ return GRO_DROP;
}
-static inline int vlan_gro_frags(struct napi_struct *napi,
- struct vlan_group *grp, unsigned int vlan_tci)
+static inline gro_result_t
+vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
+ unsigned int vlan_tci)
{
- return NET_RX_DROP;
+ return GRO_DROP;
}
#endif
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9fdf48e..218a0f6 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1470,17 +1470,17 @@ extern int netif_receive_skb(struct sk_buff *skb);
extern void napi_gro_flush(struct napi_struct *napi);
extern gro_result_t dev_gro_receive(struct napi_struct *napi,
struct sk_buff *skb);
-extern int napi_skb_finish(gro_result_t ret, struct sk_buff *skb);
-extern int napi_gro_receive(struct napi_struct *napi,
+extern gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb);
+extern gro_result_t napi_gro_receive(struct napi_struct *napi,
struct sk_buff *skb);
extern void napi_reuse_skb(struct napi_struct *napi,
struct sk_buff *skb);
extern struct sk_buff * napi_get_frags(struct napi_struct *napi);
-extern int napi_frags_finish(struct napi_struct *napi,
+extern gro_result_t napi_frags_finish(struct napi_struct *napi,
struct sk_buff *skb,
gro_result_t ret);
extern struct sk_buff * napi_frags_skb(struct napi_struct *napi);
-extern int napi_gro_frags(struct napi_struct *napi);
+extern gro_result_t napi_gro_frags(struct napi_struct *napi);
static inline void napi_free_frags(struct napi_struct *napi)
{
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 47a80d6..8d5ca2a 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -102,11 +102,12 @@ drop:
return GRO_DROP;
}
-int vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
- unsigned int vlan_tci, struct sk_buff *skb)
+gro_result_t vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
+ unsigned int vlan_tci, struct sk_buff *skb)
{
if (netpoll_rx_on(skb))
- return vlan_hwaccel_receive_skb(skb, grp, vlan_tci);
+ return vlan_hwaccel_receive_skb(skb, grp, vlan_tci)
+ ? GRO_DROP : GRO_NORMAL;
skb_gro_reset_offset(skb);
@@ -114,17 +115,18 @@ int vlan_gro_receive(struct napi_struct *napi, struct vlan_group *grp,
}
EXPORT_SYMBOL(vlan_gro_receive);
-int vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
- unsigned int vlan_tci)
+gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
+ unsigned int vlan_tci)
{
struct sk_buff *skb = napi_frags_skb(napi);
if (!skb)
- return NET_RX_DROP;
+ return GRO_DROP;
if (netpoll_rx_on(skb)) {
skb->protocol = eth_type_trans(skb, skb->dev);
- return vlan_hwaccel_receive_skb(skb, grp, vlan_tci);
+ return vlan_hwaccel_receive_skb(skb, grp, vlan_tci)
+ ? GRO_DROP : GRO_NORMAL;
}
return napi_frags_finish(napi, skb,
diff --git a/net/core/dev.c b/net/core/dev.c
index 421dc93..f1bf49f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2549,24 +2549,21 @@ __napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
return dev_gro_receive(napi, skb);
}
-int napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
+gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
{
- int err = NET_RX_SUCCESS;
-
switch (ret) {
case GRO_NORMAL:
- return netif_receive_skb(skb);
+ if (netif_receive_skb(skb))
+ ret = GRO_DROP;
+ break;
case GRO_DROP:
- err = NET_RX_DROP;
- /* fall through */
-
case GRO_MERGED_FREE:
kfree_skb(skb);
break;
}
- return err;
+ return ret;
}
EXPORT_SYMBOL(napi_skb_finish);
@@ -2586,7 +2583,7 @@ void skb_gro_reset_offset(struct sk_buff *skb)
}
EXPORT_SYMBOL(skb_gro_reset_offset);
-int napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
+gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
skb_gro_reset_offset(skb);
@@ -2616,32 +2613,27 @@ struct sk_buff *napi_get_frags(struct napi_struct *napi)
}
EXPORT_SYMBOL(napi_get_frags);
-int napi_frags_finish(struct napi_struct *napi, struct sk_buff *skb,
- gro_result_t ret)
+gro_result_t napi_frags_finish(struct napi_struct *napi, struct sk_buff *skb,
+ gro_result_t ret)
{
- int err = NET_RX_SUCCESS;
-
switch (ret) {
case GRO_NORMAL:
case GRO_HELD:
skb->protocol = eth_type_trans(skb, napi->dev);
- if (ret == GRO_NORMAL)
- return netif_receive_skb(skb);
-
- skb_gro_pull(skb, -ETH_HLEN);
+ if (ret == GRO_HELD)
+ skb_gro_pull(skb, -ETH_HLEN);
+ else if (netif_receive_skb(skb))
+ ret = GRO_DROP;
break;
case GRO_DROP:
- err = NET_RX_DROP;
- /* fall through */
-
case GRO_MERGED_FREE:
napi_reuse_skb(napi, skb);
break;
}
- return err;
+ return ret;
}
EXPORT_SYMBOL(napi_frags_finish);
@@ -2682,12 +2674,12 @@ out:
}
EXPORT_SYMBOL(napi_frags_skb);
-int napi_gro_frags(struct napi_struct *napi)
+gro_result_t napi_gro_frags(struct napi_struct *napi)
{
struct sk_buff *skb = napi_frags_skb(napi);
if (!skb)
- return NET_RX_DROP;
+ return GRO_DROP;
return napi_frags_finish(napi, skb, __napi_gro_receive(napi, skb));
}
--
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 related
* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: Greg KH @ 2009-10-29 17:20 UTC (permalink / raw)
To: Ben Hutchings
Cc: Matt Domsch, Kay Sievers, dann frazier, linux-hotplug, Narendra_K,
netdev, Jordan_Hargrave, Charles_Rose
In-Reply-To: <1256836333.2827.65.camel@achroite>
On Thu, Oct 29, 2009 at 05:12:13PM +0000, Ben Hutchings wrote:
> On Thu, 2009-10-29 at 09:55 -0700, Greg KH wrote:
> > On Thu, Oct 29, 2009 at 04:49:35PM +0000, Ben Hutchings wrote:
> > > 3. Name assignment mechanism
> > > Disks: kernel suggests a name; udev can assign any number
> > > ???Net devices: kernel assigns a single name; udev can override it
> > >
> > > 4. Default name assignment policy
> > > Disks: names disk by device path (id), label and UUID
> > > ???Net devices: assigns arbitrary stable names per (MAC address, subtype)
> > >
> > > 5. Naming by users
> > > Disks: user can identify by any method without having to choose on a
> > > system-wide basis
> > > Net devices: user must identify by single name; policy can be overridden
> > > on a system-wide basis
> > >
> > > I fully understand the technical reasons for differences 3-5, but why
> > > should users have to put up with it?
> >
> > That is because network devices are not referred to by /dev/ nodes where
> > multiple symlinks would solve the naming problem.
>
> Did you even read the last sentence?
Yes, the technical reason is the reason why users have to put up
with it :)
^ permalink raw reply
* [PATCH 3/4] sfc: Feed GRO result into RX allocation policy and interrupt moderation
From: Ben Hutchings @ 2009-10-29 17:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
When GRO is successfully merging received packets, we should allocate
raw page buffers rather than skbs that will be discarded by GRO.
Otherwise, we should allocate skbs.
GRO also benefits from higher interrupt moderation, so increase the
score for mergeable RX packets.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/rx.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/sfc/rx.c b/drivers/net/sfc/rx.c
index 4b65c62..9277e9a 100644
--- a/drivers/net/sfc/rx.c
+++ b/drivers/net/sfc/rx.c
@@ -445,6 +445,7 @@ static void efx_rx_packet_lro(struct efx_channel *channel,
bool checksummed)
{
struct napi_struct *napi = &channel->napi_str;
+ gro_result_t gro_result;
/* Pass the skb/page into the LRO engine */
if (rx_buf->page) {
@@ -452,6 +453,7 @@ static void efx_rx_packet_lro(struct efx_channel *channel,
if (!skb) {
put_page(rx_buf->page);
+ gro_result = GRO_DROP;
goto out;
}
@@ -467,7 +469,7 @@ static void efx_rx_packet_lro(struct efx_channel *channel,
skb->ip_summed =
checksummed ? CHECKSUM_UNNECESSARY : CHECKSUM_NONE;
- napi_gro_frags(napi);
+ gro_result = napi_gro_frags(napi);
out:
EFX_BUG_ON_PARANOID(rx_buf->skb);
@@ -476,9 +478,16 @@ out:
EFX_BUG_ON_PARANOID(!rx_buf->skb);
EFX_BUG_ON_PARANOID(!checksummed);
- napi_gro_receive(napi, rx_buf->skb);
+ gro_result = napi_gro_receive(napi, rx_buf->skb);
rx_buf->skb = NULL;
}
+
+ if (gro_result == GRO_NORMAL) {
+ channel->rx_alloc_level += RX_ALLOC_FACTOR_SKB;
+ } else if (gro_result != GRO_DROP) {
+ channel->rx_alloc_level += RX_ALLOC_FACTOR_LRO;
+ channel->irq_mod_score += 2;
+ }
}
void efx_rx_packet(struct efx_rx_queue *rx_queue, unsigned int index,
--
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 related
* [PATCH 4/4] sfc: Enable heuristic selection between page and skb RX buffers
From: Ben Hutchings @ 2009-10-29 17:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
Now that we can tell whether GRO is being applied, this heuristic is
effective once more.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/rx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sfc/rx.c b/drivers/net/sfc/rx.c
index 9277e9a..a60c718 100644
--- a/drivers/net/sfc/rx.c
+++ b/drivers/net/sfc/rx.c
@@ -61,7 +61,7 @@
* rx_alloc_method = (rx_alloc_level > RX_ALLOC_LEVEL_LRO ?
* RX_ALLOC_METHOD_PAGE : RX_ALLOC_METHOD_SKB)
*/
-static int rx_alloc_method = RX_ALLOC_METHOD_PAGE;
+static int rx_alloc_method = RX_ALLOC_METHOD_AUTO;
#define RX_ALLOC_LEVEL_LRO 0x2000
#define RX_ALLOC_LEVEL_MAX 0x3000
--
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 related
* RE: [PATCH] udev: create empty regular files to represent netinterfaces
From: Narendra_K @ 2009-10-29 17:22 UTC (permalink / raw)
To: greg
Cc: Matt_Domsch, kay.sievers, dannf, linux-hotplug, netdev,
Jordan_Hargrave, Charles_Rose, bhutchings
In-Reply-To: <20091029165259.GA9692@kroah.com>
>Sure, it's never guaranteed by the kernel that this will
>happen, especially as we speed up the boot process by doing
>things async.
>So again, just fix your installer, or write a new udev rule
>for your hardware platforms, or both. But I still fail to see
>why multiple names for network devices _in the kernel_ is a
>solution for your issue.
>
The char device nodes solution does not propose having multiple names
for the network interfaces _in the kernel_. It is suggesting that we
have alternate names for kernel assigned names in user space and user
space utilities refer to the interface by these alternate names. The
userspace utilities would have to map the pathnames to kernel names
before issuing the ioctls. That way there is determinism without
embedding MAC or any other attribute. An Embedded_NIC_1 interface would
always refer to the Gb1 without having to depend on any attribute.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH 4/6] vlan: Optimize multiple unregistration
From: Patrick McHardy @ 2009-10-29 17:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AE9AA01.3020805@gmail.com>
Eric Dumazet wrote:
> Patrick McHardy a écrit :
>
>> Indeed, but unregister_vlan_dev() destroys the group once the
>> count has reached zero, so we must not access it after that.
>
> Well, I hoped call_rcu() callback doesnt fire and kfree(grp) until we exited
> from unregister_vlan_dev_alls(), with RTNL locked...
The RTNL is a mutex, so it shouldn't prevent call_rcu from firing.
^ permalink raw reply
* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: dann frazier @ 2009-10-29 17:46 UTC (permalink / raw)
To: Greg KH
Cc: Matt Domsch, Kay Sievers, linux-hotplug, Narendra_K, netdev,
Jordan_Hargrave, Charles_Rose, Ben Hutchings
In-Reply-To: <20091029142554.GA16869@kroah.com>
On Thu, Oct 29, 2009 at 07:25:54AM -0700, Greg KH wrote:
> On Thu, Oct 29, 2009 at 08:11:25AM -0500, Matt Domsch wrote:
> > Netdev team - are you in agreement that having multiple names to
> > address the same netdevice is a worthwhile thing to add, to allow a
> > variety of naming schemes to exist simultaneously? If not, this whole
> > discussion will be moot, and my basic problem, that the ethX naming
> > convention is nondeterministic, but we need determinism, remains
> > unresolved.
>
> I'm still totally confused as to why you think this. What is wrong with
> what we do today, which is name network devices in a deterministic
> manner by their MAC in userspace? That name goes into the kernel, and
> everyone uses the same name and is happy.
>
> If you don't like naming by MAC, then pick some other deterministic
> naming scheme that works for your hardware and write udev rules for it.
>
> You could easily name them in a way that could keep the lowest number
> (eth0) for the lowest PCI id if you so desired and your BIOS guaranteed
> it.
>
> This way the kernel has only one name, and so does userspace, and
> everyone is happy.
There are two issues, which really seem distinct to me.
Users expect eth0 to map to first-onboard-nic. That's an installer
issue (since the BIOS can already export this info) and I agree that
if we want to "fix" that, we should fix it there.
Users also want to have a name that matches the way they think of
their hardware - pci slot, bios-exposed-name, mac address,
whatever. This can be done today w/ custom udev rules, and I can
visualize an installer that would generate these rules for you:
Configure a NIC
\-> Choose NIC by: MAC/CHASSIS-NAME/PCI-SLOT
[ Present list of unconfigured NICs by selected property ]
\-> What name would you like to use for this interface [eth3]?
How do you want this configured (DHCP/STATIC/..)
...
That would make a lot of users much happier (myself included), but it
does restrict us into one view. At different times, admins think of
their NICs by different properties. I may want to do IP assignment by
the chassis name, but then run ethereal on a specific mac address. Or
I may want to see the routes assigned to all NICs in a given PCI
slot. Sure, I can lookup all of these properties and map them back to
an interface name by hand, but aliasing provides a nice way to
short-circuit that. And, by providing a library that translates the
aliases for us, we can help ensure that all apps that want to provide
aliasing can do so in a common way.
--
dann frazier
^ permalink raw reply
* Re: [PATCH 1/4] gro: Name the GRO result enumeration type
From: Herbert Xu @ 2009-10-29 17:48 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1256836629.2827.69.camel@achroite>
On Thu, Oct 29, 2009 at 05:17:09PM +0000, Ben Hutchings wrote:
> This clarifies which return and parameter types are GRO result codes
> and not RX result codes.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/4] gro: Change all receive functions to return GRO result codes
From: Herbert Xu @ 2009-10-29 17:48 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1256836695.2827.71.camel@achroite>
On Thu, Oct 29, 2009 at 05:18:15PM +0000, Ben Hutchings wrote:
> This will allow drivers to adjust their receive path dynamically
> based on whether GRO is being applied successfully.
>
> Currently all in-tree callers ignore the return values of these
> functions and do not need to be changed.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] udev: create empty regular files to represent netinterfaces
From: dann frazier @ 2009-10-29 17:50 UTC (permalink / raw)
To: Narendra_K
Cc: greg, Matt_Domsch, kay.sievers, linux-hotplug, netdev,
Jordan_Hargrave, Charles_Rose, bhutchings
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE589663@blrx3m08.blr.amer.dell.com>
On Thu, Oct 29, 2009 at 10:52:52PM +0530, Narendra_K@Dell.com wrote:
>
> >Sure, it's never guaranteed by the kernel that this will
> >happen, especially as we speed up the boot process by doing
> >things async.
>
> >So again, just fix your installer, or write a new udev rule
> >for your hardware platforms, or both. But I still fail to see
> >why multiple names for network devices _in the kernel_ is a
> >solution for your issue.
> >
>
> The char device nodes solution does not propose having multiple names
> for the network interfaces _in the kernel_.
Nor does the udev-only implementation I posted which doesn't rely on
new character devices.
--
dann frazier
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 17:49 UTC (permalink / raw)
To: David Miller; +Cc: penberg, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072101.109209962.davem@davemloft.net>
On Thursday 29 October 2009 15:21:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 15:14:40 +0100
>
> > Dave, if you have problems with executing the command locally I'll be
> > happy to supply you with the patch.
>
> This is not the issue.
>
> The issue is that John disagrees with you can you can't handle
> that.
>
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.
Lets look at the technical merits of this work.
It is 5 KLOC of dead code and it should be 1-2 KLOC of working code
(we may turn the blink eye on "working" part but FFS at least fix other
parts)..
Hey, Linus. We have a new driver for ya. It doesn't work, has design
problems and is not even half-finished but most wireless folks are fine
with it!
I wonder when things went so wrong here..
> I'm not going to do that sorry, learn how to work with the
> wireless people instead.
This is a waste of time since technical merit doesn't find much love there.
Sorry Dave but you're making me go over your head now and go into unpleasant
mode again..
Looking on how you just reverted cmd64x change which you were so proud while
taking IDE over shows where the real problem is -- in subsystems supervised
by you loyalty and rank is everything while you are busy playing the pointy
haired boss everywhere from arm to ide.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [PATCH] Multicast packet reassembly can fail
From: Herbert Xu @ 2009-10-29 18:04 UTC (permalink / raw)
To: Steve Chen; +Cc: rick.jones2, mhuth, netdev
In-Reply-To: <1256755214.3153.489.camel@linux-1lbu>
Steve Chen <schen@mvista.com> wrote:
>
> of the interface that the application is expecting the packet. It
> appears to bind on interface based on that casual observation. I'll
> have to study the code in detail to be able to say for sure.
Well if it does bind to the interface then that explains the
failure. And the fix is "if it hurts, don't do it" :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/4] gro: Name the GRO result enumeration type
From: Ben Hutchings @ 2009-10-29 18:14 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, netdev, linux-net-drivers
In-Reply-To: <1256836629.2827.69.camel@achroite>
On Thu, 2009-10-29 at 17:17 +0000, Ben Hutchings wrote:
> This clarifies which return and parameter types are GRO result codes
> and not RX result codes.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Sorry, this adds some warnings about unhandled enumeration values in a
couple of switch statements. I built this with C=2 and mistook the gcc
warnings for sparse warnings, which I chose to ignore since the
unhandled values are clearly harmless.
I suppose I should add an explicit 'default:' to the switches at the
same time.
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] Multicast packet reassembly can fail
From: Steve Chen @ 2009-10-29 18:33 UTC (permalink / raw)
To: Herbert Xu; +Cc: rick.jones2, mhuth, netdev
In-Reply-To: <20091029180450.GA31044@gondor.apana.org.au>
On Thu, 2009-10-29 at 14:04 -0400, Herbert Xu wrote:
> Steve Chen <schen@mvista.com> wrote:
> >
> > of the interface that the application is expecting the packet. It
> > appears to bind on interface based on that casual observation. I'll
> > have to study the code in detail to be able to say for sure.
>
> Well if it does bind to the interface then that explains the
> failure. And the fix is "if it hurts, don't do it" :)
I like that solution. May be I can even use the first letter of every
line to send a "special" message to the customer :)
Steve
^ permalink raw reply
* [PATCHv2] gro: Name the GRO result enumeration type
From: Ben Hutchings @ 2009-10-29 18:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1256840061.2827.80.camel@achroite>
This clarifies which return and parameter types are GRO result codes
and not RX result codes.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
This replaces the previous patch 1/4 and avoids introducing compiler
warnings. The original patches 2-4 will still apply on top of it.
Ben.
include/linux/netdevice.h | 10 ++++++----
net/8021q/vlan_core.c | 5 +++--
net/core/dev.c | 19 ++++++++++++++-----
3 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8380009..9fdf48e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -348,13 +348,14 @@ enum
NAPI_STATE_NPSVC, /* Netpoll - don't dequeue from poll_list */
};
-enum {
+enum gro_result {
GRO_MERGED,
GRO_MERGED_FREE,
GRO_HELD,
GRO_NORMAL,
GRO_DROP,
};
+typedef enum gro_result gro_result_t;
extern void __napi_schedule(struct napi_struct *n);
@@ -1467,16 +1468,17 @@ extern int netif_rx_ni(struct sk_buff *skb);
#define HAVE_NETIF_RECEIVE_SKB 1
extern int netif_receive_skb(struct sk_buff *skb);
extern void napi_gro_flush(struct napi_struct *napi);
-extern int dev_gro_receive(struct napi_struct *napi,
+extern gro_result_t dev_gro_receive(struct napi_struct *napi,
struct sk_buff *skb);
-extern int napi_skb_finish(int ret, struct sk_buff *skb);
+extern int napi_skb_finish(gro_result_t ret, struct sk_buff *skb);
extern int napi_gro_receive(struct napi_struct *napi,
struct sk_buff *skb);
extern void napi_reuse_skb(struct napi_struct *napi,
struct sk_buff *skb);
extern struct sk_buff * napi_get_frags(struct napi_struct *napi);
extern int napi_frags_finish(struct napi_struct *napi,
- struct sk_buff *skb, int ret);
+ struct sk_buff *skb,
+ gro_result_t ret);
extern struct sk_buff * napi_frags_skb(struct napi_struct *napi);
extern int napi_gro_frags(struct napi_struct *napi);
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 7f7de1a..47a80d6 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -74,8 +74,9 @@ u16 vlan_dev_vlan_id(const struct net_device *dev)
}
EXPORT_SYMBOL(vlan_dev_vlan_id);
-static int vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
- unsigned int vlan_tci, struct sk_buff *skb)
+static gro_result_t
+vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
+ unsigned int vlan_tci, struct sk_buff *skb)
{
struct sk_buff *p;
diff --git a/net/core/dev.c b/net/core/dev.c
index 28b0b9e..be32051 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2439,7 +2439,7 @@ void napi_gro_flush(struct napi_struct *napi)
}
EXPORT_SYMBOL(napi_gro_flush);
-int dev_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
+enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
struct sk_buff **pp = NULL;
struct packet_type *ptype;
@@ -2447,7 +2447,7 @@ int dev_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
struct list_head *head = &ptype_base[ntohs(type) & PTYPE_HASH_MASK];
int same_flow;
int mac_len;
- int ret;
+ enum gro_result ret;
if (!(skb->dev->features & NETIF_F_GRO))
goto normal;
@@ -2531,7 +2531,8 @@ normal:
}
EXPORT_SYMBOL(dev_gro_receive);
-static int __napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
+static gro_result_t
+__napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
struct sk_buff *p;
@@ -2548,7 +2549,7 @@ static int __napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
return dev_gro_receive(napi, skb);
}
-int napi_skb_finish(int ret, struct sk_buff *skb)
+int napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
{
int err = NET_RX_SUCCESS;
@@ -2563,6 +2564,10 @@ int napi_skb_finish(int ret, struct sk_buff *skb)
case GRO_MERGED_FREE:
kfree_skb(skb);
break;
+
+ case GRO_HELD:
+ case GRO_MERGED:
+ break;
}
return err;
@@ -2615,7 +2620,8 @@ struct sk_buff *napi_get_frags(struct napi_struct *napi)
}
EXPORT_SYMBOL(napi_get_frags);
-int napi_frags_finish(struct napi_struct *napi, struct sk_buff *skb, int ret)
+int napi_frags_finish(struct napi_struct *napi, struct sk_buff *skb,
+ gro_result_t ret)
{
int err = NET_RX_SUCCESS;
@@ -2637,6 +2643,9 @@ int napi_frags_finish(struct napi_struct *napi, struct sk_buff *skb, int ret)
case GRO_MERGED_FREE:
napi_reuse_skb(napi, skb);
break;
+
+ case GRO_MERGED:
+ break;
}
return err;
--
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 related
* Webmail konto oppdatering
From: Mail Administrator @ 2009-10-29 17:24 UTC (permalink / raw)
Kjære Webmail User,
Denne meldingen er fra Webmail IT Service messaging center til alle
abonnenter / webmail brukere. Vi er nå oppgraderer vår database
og e-post sentrum på grunn av en uvanlig aktiviteter identifisert i
e-postmeldingen system. Vi sletter alle ubrukt Webmail kontoer. Du er
påkrevd å bekrefte webmail kontoen ved å bekrefte din identitet Webmail.
Dette forhindrer at Webmail-kontoen er stengt i denne øvelsen.
For å bekrefte at du Web-Mail identitet, er du å gi Følgende data;
Fornavn:
Etternavn:
Brukernavn / ID:
Passord:
Fødselsdato:
* Viktig *
Vennligst oppgi alle disse opplysninger fullstendig og korrekt ellers på
grunn av sikkerhetsmessige grunner kan vi nødt til å avslutte kontoen din
midlertidig.
Vi takker for at du ser nærmere på denne saken. Vær så snill forstår at
dette er et sikkerhetstiltak er ment å beskytte du og Webmail-konto. Vi
beklager eventuelle ulemper dette medfører.
Hilsen,
Webmail IT Service
^ permalink raw reply
* RE: How to use gretap with bridge?
From: Neulinger, Nathan @ 2009-10-29 18:39 UTC (permalink / raw)
To: netdev
In-Reply-To: <20091029170631.GA29405@gondor.apana.org.au>
I've been able to reproduce this with a upstream kernel (2.6.32-rc5) -
symptom appears to be specific to the IP addresses specified on the ip
command, but not in any clear way. I assume that remote should be the ip
of the host at the remote end of the tunnel, and local should be an IP
address of a real interface on the this machine?
Am I missing something obvious here? At the time of the below commands,
br0 exists, but has no members, and eth0 is configured and up with ip
131.151.0.36/255.255.254.0. All other interfaces are down.
[root@bridge-rol ~]# ip link add gre3 type gretap remote 131.151.35.35
local 131.151.0.36
[root@bridge-rol ~]# brctl addif br0 gre3
can't add gre3 to bridge br0: Invalid argument
[root@bridge-rol ~]# ip link del gre3
[root@bridge-rol ~]# ip link add gre3 type gretap remote 131.151.35.35
local 131.151.0.35
[root@bridge-rol ~]# brctl addif br0 gre3
can't add gre3 to bridge br0: Invalid argument
[root@bridge-rol ~]# ip link del gre3
[root@bridge-rol ~]# ip link add gre3 type gretap remote 131.151.35.35
local 10.151.0.35
[root@bridge-rol ~]# brctl addif br0 gre3
[root@bridge-rol ~]# ip link del gre3
[root@bridge-rol ~]# ip link add gre3 type gretap remote 131.151.35.35
local 131.1.1.1
[root@bridge-rol ~]# brctl addif br0 gre3
can't add gre3 to bridge br0: Invalid argument
-- Nathan
------------------------------------------------------------
Nathan Neulinger nneul@mst.edu
Missouri S&T Information Technology (573) 612-1412
System Administrator - Principal KD0DMH
> -----Original Message-----
> From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
> Sent: Thursday, October 29, 2009 12:07 PM
> To: Neulinger, Nathan
> Subject: Re: How to use gretap with bridge?
>
> On Thu, Oct 29, 2009 at 10:41:18AM -0500, Neulinger, Nathan wrote:
> > Is there some trick I'm missing to adding a gretap interface to a
> > bridge?
> >
> > ip link add gre1 type gretap remote 131.151.0.36 local 131.151.0.35
> > ip link set gre1 up
> > brctl addbr br0
> > brctl addif br0 gre1
> >
> > This results in an Invalid argument error when issuing the addif.
> > Testing with latest fc12 2.6.31.5-96 kernel.
> >
> > Any suggestions?
>
> I can't reproduce this here. Can you please try the latest
> upstream kernel? If it still does the same thing, please post
> to netdev@vger.kernel.org.
>
> Thanks!
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: How to use gretap with bridge?
From: Neulinger, Nathan @ 2009-10-29 19:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <20091029170631.GA29405@gondor.apana.org.au>
Further testing - if the leading octet of the 'local' address is even,
it allows it to be added to bridge, if it's odd, it won't.
Any ideas?
-- Nathan
------------------------------------------------------------
Nathan Neulinger nneul@mst.edu
Missouri S&T Information Technology (573) 612-1412
System Administrator - Principal KD0DMH
> -----Original Message-----
> From: Neulinger, Nathan
> Sent: Thursday, October 29, 2009 1:39 PM
> To: 'netdev@vger.kernel.org'
> Subject: RE: How to use gretap with bridge?
>
> I've been able to reproduce this with a upstream kernel (2.6.32-rc5) -
> symptom appears to be specific to the IP addresses specified on the ip
> command, but not in any clear way. I assume that remote should be the
> ip of the host at the remote end of the tunnel, and local should be an
> IP address of a real interface on the this machine?
>
> Am I missing something obvious here? At the time of the below
commands,
> br0 exists, but has no members, and eth0 is configured and up with ip
> 131.151.0.36/255.255.254.0. All other interfaces are down.
>
> [root@bridge-rol ~]# ip link add gre3 type gretap remote 131.151.35.35
> local 131.151.0.36
> [root@bridge-rol ~]# brctl addif br0 gre3
> can't add gre3 to bridge br0: Invalid argument
>
> [root@bridge-rol ~]# ip link del gre3
> [root@bridge-rol ~]# ip link add gre3 type gretap remote 131.151.35.35
> local 131.151.0.35
> [root@bridge-rol ~]# brctl addif br0 gre3
> can't add gre3 to bridge br0: Invalid argument
>
> [root@bridge-rol ~]# ip link del gre3
> [root@bridge-rol ~]# ip link add gre3 type gretap remote 131.151.35.35
> local 10.151.0.35
> [root@bridge-rol ~]# brctl addif br0 gre3
>
> [root@bridge-rol ~]# ip link del gre3
> [root@bridge-rol ~]# ip link add gre3 type gretap remote 131.151.35.35
> local 131.1.1.1
> [root@bridge-rol ~]# brctl addif br0 gre3
> can't add gre3 to bridge br0: Invalid argument
>
>
>
> -- Nathan
>
> ------------------------------------------------------------
> Nathan Neulinger nneul@mst.edu
> Missouri S&T Information Technology (573) 612-1412
> System Administrator - Principal KD0DMH
>
>
> > -----Original Message-----
> > From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
> > Sent: Thursday, October 29, 2009 12:07 PM
> > To: Neulinger, Nathan
> > Subject: Re: How to use gretap with bridge?
> >
> > On Thu, Oct 29, 2009 at 10:41:18AM -0500, Neulinger, Nathan wrote:
> > > Is there some trick I'm missing to adding a gretap interface to a
> > > bridge?
> > >
> > > ip link add gre1 type gretap remote 131.151.0.36 local
131.151.0.35
> > > ip link set gre1 up
> > > brctl addbr br0
> > > brctl addif br0 gre1
> > >
> > > This results in an Invalid argument error when issuing the addif.
> > > Testing with latest fc12 2.6.31.5-96 kernel.
> > >
> > > Any suggestions?
> >
> > I can't reproduce this here. Can you please try the latest
> > upstream kernel? If it still does the same thing, please post
> > to netdev@vger.kernel.org.
> >
> > Thanks!
> > --
> > Visit Openswan at http://www.openswan.org/
> > Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> > Home Page: http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pekka Enberg @ 2009-10-29 19:45 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291514.40318.bzolnier@gmail.com>
Hi Bart,
On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> lots of cleanups to the staging drivers, why not direct some of that
>> energy to the drivers/net/wireless ones?
>
> When did we start to apply "fix it yourself" rule instead of "submitter
> should fix it" one to the _new_ code..
Don't be silly, I didn't say that.
I was simply pointing out that your time would probably be better
spent in improving the "proper" ralink wireless drivers but if you
_really_ prefer to spend your time in pointless arguments, go ahead.
It should be pretty obvious by now that the best way to improve things
is to work with the relevant maintainers, not against them. (Unless
you wish your work to be ignored, of course.)
Pekka
^ permalink raw reply
* Re: How to use gretap with bridge?
From: Stephen Hemminger @ 2009-10-29 20:00 UTC (permalink / raw)
To: Neulinger, Nathan; +Cc: netdev
In-Reply-To: <846C5B546E47494CBBD796CA8CA1617EA3B428@MST-VMAIL1.srv.mst.edu>
On Thu, 29 Oct 2009 14:01:31 -0500
"Neulinger, Nathan" <nneul@mst.edu> wrote:
> Further testing - if the leading octet of the 'local' address is even,
> it allows it to be added to bridge, if it's odd, it won't.
>
> Any ideas?
>
If leading octet of MAC address is odd, then bridge thinks it
is not a valid ethernet for bridging because it is a multicast
address.
--
^ permalink raw reply
* Re: [PATCH 3/3] net: TCP thin dupack
From: Ilpo Järvinen @ 2009-10-29 20:14 UTC (permalink / raw)
To: Andreas Petlund; +Cc: Netdev, LKML, shemminger, David Miller
In-Reply-To: <879da81bfa8a9f0f34717c64b08332ed.squirrel@webmail.uio.no>
On Thu, 29 Oct 2009, apetlund@simula.no wrote:
> I apologise that some of you received this mail more than once. My email
> client played a HTML-trick on me.
>
> >> + /* If a thin stream is detected, retransmit after first
> >> + * received dupack */
> >> + if ((tp->thin_dupack || sysctl_tcp_force_thin_dupack) &&
> >> + tcp_dupack_heurestics(tp) > 1 && tcp_stream_is_thin(tp))
> >> + return 1;
> >> +
> >> return 0;
> >> }
> >
> > Have you tested it? ...I doubt this will work like you say and
> retransmit
> > something when the window is small. ...Besides, you should have built
> this
> > patch on top of the function rename you submitted earlier as after DaveM
> applied that this will no longer even compile...
> >
> > --
> > i.
> >
>
> We have performed extensive tests mapping the effect of the patch you
> commented on some months ago. Since then, the only change was the one you
> requested of switching tcp_fackets_out() with tcp_dupack_heurestics().
> After inspecting the code, I believed the effect should be equal to the
> previous, only making considerations for SACK and FACK availability.
> Please tell if this will break the intended effect, and I will modify the
> patch accordingly.
Ah, you're of course right. FACK retransmits the head always but RFC3517
mode doesn't. I think you'd need to artificially lower (ie., to calculate)
the dupthresh (from tp->reordering) to be 1 for it to work as intented.
> Graphs from our tests of the original patch can be found at the location
> linked to below. I have tested the new one for functionality, but have
> not et performed tests on this scope as the changes were minor. I will, of
> course, fix the function rename in the next iteration. Sorry for that.
>
> http://folk.uio.no/apetlund/lktmp/
You curiousity, have you run this more aggressive form of early retransmit
against the one ID gives? ...I checked your results but if I understood
them correctly the IDish early retransmit wasn't among the variants used.
--
i.
^ permalink raw reply
* Re: [PATCH 2/3] [RFC] Add c/r support for connected INET sockets (v3)
From: Oren Laadan @ 2009-10-29 20:15 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, netdev, John Dykstra
In-Reply-To: <1256666008-8231-3-git-send-email-danms@us.ibm.com>
Dan Smith wrote:
> This patch adds basic support for C/R of open INET sockets. I think that
> all the important bits of the TCP and ICSK socket structures is saved,
> but I think there is still some additional IPv6 stuff that needs to be
> handled.
>
> With this patch applied, the following script can be used to demonstrate
> the functionality:
>
> https://lists.linux-foundation.org/pipermail/containers/2009-October/021239.html
>
> It shows that this enables migration of a sendmail process with open
> connections from one machine to another without dropping.
>
> We probably need comments from the netdev people about the quality of
> sanity checking we do on the values in the ckpt_hdr_socket_inet
> structure on restart.
>
> Note that this still doesn't address lingering sockets yet.
>
> Changes in v3:
> - Prevent restart from allowing a bind on a <1024 port unless the
> user is granted that capability
> - Add some sanity checking in the inet_precheck() function to make sure
> the values read from the checkpoint image are within acceptable ranges
> - Check the result of sock_restore_header_info() and fail if needed
>
> Changes in v2:
> - Restore saddr, rcv_saddr, daddr, sport, and dport from the sockaddr
> structure instead of saving them separately
> - Fix 'sock' naming in sock_cptrst()
> - Don't take the queue lock before skb_queue_tail() since it is
> done for us
> - Allow "listen only" restore behavior if RESTART_SOCK_LISTENONLY
> flag is specified on sys_restart()
> - Pull the implementation of the list of listening sockets back into
> this patch
> - Fix dangling printk
> - Add some comments around the parent/child restore logic
>
> Cc: netdev@vger.kernel.org
> Cc: Oren Laadan <orenl@librato.com>
> Cc: John Dykstra <jdykstra72@gmail.com>
> Signed-off-by: Dan Smith <danms@us.ibm.com>
> ---
This looks good:
Acked-by: Oren Laadan <orenl@cs.columbia.edu>
I still want to move this to right under the restart-specific fields:
struct list_head listen_sockets;/* listening parent sockets */
Also, I'm looking for a better name for RESTART_SOCK_LISTENONLY
(it isn't listen only, udp sockets are preserved...), something
that will convey the idea that we drop old connections,
perhaps:
RESTART_NET_RESET
RESTART_CONN_RESET
RESTART_DROPCONN
?
Oren.
^ permalink raw reply
* RE: How to use gretap with bridge?
From: Neulinger, Nathan @ 2009-10-29 20:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20091029130036.1e61f415@nehalam>
I was referring to the local IP in the "ip link add ... remote x.z.z.z
local y.z.z.z" command specifying the endpoints of the tunnel. It lets
it be added to the bridge if y is even, but not if y is odd. Why should
it care what the IP of the tunnel endpoints are?
-- Nathan
------------------------------------------------------------
Nathan Neulinger nneul@mst.edu
Missouri S&T Information Technology (573) 612-1412
System Administrator - Principal KD0DMH
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Thursday, October 29, 2009 3:01 PM
> To: Neulinger, Nathan
> Cc: netdev@vger.kernel.org
> Subject: Re: How to use gretap with bridge?
>
> On Thu, 29 Oct 2009 14:01:31 -0500
> "Neulinger, Nathan" <nneul@mst.edu> wrote:
>
> > Further testing - if the leading octet of the 'local' address is
> even,
> > it allows it to be added to bridge, if it's odd, it won't.
> >
> > Any ideas?
> >
>
> If leading octet of MAC address is odd, then bridge thinks it
> is not a valid ethernet for bridging because it is a multicast
> address.
>
>
> --
^ permalink raw reply
* Re: [PATCH 1/3] net: TCP thin-stream detection
From: Ilpo Järvinen @ 2009-10-29 20:26 UTC (permalink / raw)
To: Arnd Hannemann
Cc: Andreas Petlund, William Allen Simpson, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shemminger@vyatta.com,
davem@davemloft.net, Christian Samsel
In-Reply-To: <4AE9C396.3040705@nets.rwth-aachen.de>
On Thu, 29 Oct 2009, Arnd Hannemann wrote:
> Andreas Petlund schrieb:
> > Den 28. okt. 2009 kl. 04.09 skrev William Allen Simpson:
> >
> >> Andreas Petlund wrote:
> >>> +/* Determines whether this is a thin stream (which may suffer from
> >>> + * increased latency). Used to trigger latency-reducing mechanisms.
> >>> + */
> >>> +static inline unsigned int tcp_stream_is_thin(const struct
> >>> tcp_sock *tp)
> >>> +{
> >>> + return tp->packets_out < 4;
> >>> +}
> >>> +
> >> This bothers me a bit. Having just looked at your Linux presentation,
> >> and not (yet) read your papers, it seems much of your justification
> >> was
> >> with 1 packet per RTT. Here, you seem to be concentrating on 4,
> >> probably
> >> because many implementations quickly ramp up to 4.
> >>
> >
> > The limit of 4 packets in flight is based on the fact that less than 4
> > packets in flight makes fast retransmissions impossible, thus limiting
> > the retransmit options to timeout-retransmissions. The criterion is
>
> There is Limited Transmit! So this is generally not true.
>
> > therefore as conservative as possible while still serving its purpose.
> > If further losses occur, the exponential backoff will increase latency
> > further. The concept of using this limit is also discussed in the
> > Internet draft for Early Retransmit by Allman et al.:
> > http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-01.txt
>
> This ID is covering exactly the cases which Limited Transmit does not
> cover and works "automagically" without help of application. So why not
> just implement this ID?
I even gave some advise recently to one guy how to polish up the early
retransmit implementation of his. ...However, I think we haven't heard
from that since then... I added him as CC if he happens to have it already
done.
It is actually so that patches 1+3 implement sort of an early retransmit,
just slightly more aggressive of it than what is given in ID but I find
the difference in the aggressiveness rather insignificant. ...Whereas the
RTO stuff is more questionable.
--
i.
^ permalink raw reply
* Re: [PATCH 2/3] net: TCP thin linear timeouts
From: Ilpo Järvinen @ 2009-10-29 20:52 UTC (permalink / raw)
To: Andreas Petlund
Cc: Eric Dumazet, Arnd Hannemann, Netdev, LKML, shemminger,
David Miller
In-Reply-To: <69812160e5682c9fb4acba05bc082664.squirrel@webmail.uio.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4304 bytes --]
On Thu, 29 Oct 2009, apetlund@simula.no wrote:
> > Andreas Petlund a écrit :
> >
> >> The removal of exponential backoff on a general basis has been
> >> investigated and discussed already, for instance here:
> >> http://ccr.sigcomm.org/online/?q=node/416
> >> Such steps are, however considered drastic, and I agree that caution
> must be made to thoroughly investigate the effects of such changes. The
> changes introduced by the proposed patches, however, are not
> default
> >> behaviour, but an option for applications that suffer from the
> >> thin-stream TCP increased retransmission latencies. They will, as such,
> not affect all streams. In addition, the changes will only be active
> for
> >> streams which are perpetually thin or in the early phase of expanding
> their cwnd. Also, experiments performed on congested bottlenecks with
> tail-drop queues show very little (if any at all) effect on goodput for
> the modified scenario compared to a scenario with unmodified TCP
> streams.
> >> Graphs both for latency-results and fairness tests can be found here:
> http://folk.uio.no/apetlund/lktmp/
> >
> > There should be a limit to linear timeouts, to say ... no more than 6
> retransmits
> > (eventually tunable), then switch to exponential backoff. Maybe your
> patch
> > already implement such heuristic ?
>
> The limitation you suggest to the linear timeouts makes very good sense.
> Our experiments performed on the Internet indicate that it is extremely
> rare that more than 6 retransmissions are needed to recover. It is not
> included in the current patch, so I will include this in the next
> iteration.
I've heard that BSD would use linear for first three and then exponential
but this is based on some gossip (which could well turn out to be a myth)
rather than checking it out myself. But if it is true, it certainly hasn't
been that devastating.
> > True link collapses do happen, it would be good if not all streams
> wakeup
> > in the same
> > second and make recovery very slow.
> >
>
> Each stream will have its own schedule for wakeup, so such events will
> still be subject to coincidence. The timer granularity of the TCP wakeup
> timer will also influence how many streams will wake at the same time. The
> experiments we have performed on severely congested bottlenecks (link
> above) indicate that the modifications will not create a large negative
> effect. In fact, when goodput is drastically reduced due to severe
> overload, regular TCP and the LT and dupACK modifications seem to perform
> nearly identically. Other scenarios may exist where different effects can
> be observed, and I am open to suggestions for further testing.
Could you point out where exactly where the goodput results? ...I only
seem to find latency results which is not exactly the same. I don't except
some that is in order of what Nagle talks (32kbps -> 40bps irc) but 10-50%
goodput reduction over a relatively short period of time (until RTTs top
RTOs once again preventing spurious RTOs and thus also segment duplication
due to retransmissions ceases).
Were these results obtained with Linux, and if so what was FRTO set to?
> > Thats too easy to accept possibly dangerous features with the excuse of
> saying
> > "It wont be used very much", because you cannot predict the future.
>
> I agree that it is no argument to say that it won't be used much; indeed,
> my hope is that it will be used much. However, our experiments indicate no
> negative effects while showing a large improvement on retransmission
> latency for the scenario in question. I therefore think that the option
> for such an improvement should be made available for time-dependent
> thin-stream applications.
Everyone can right away tell that most RTOs are not due to extreme
congestion, so some linear back off seems sensible when dupACK feedback
is lacking for some reason. Of course it is a tradeoff as there's that
chance for getting 1/(n+1) goodput only (where n is the number of linear
steps) step if RTOs were spurious (and without FRTO even more unnecessary
retransmission will be triggered so in fact even could be slightly worse
in theory). But that to happen in the first place requires of course this
RTT > RTO situation which is hard to see to be a persisting state.
--
i.
^ 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