* 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: 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
* 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
* [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
* 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
* 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: 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: 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] 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: [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 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] 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 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 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
* [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
* [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
* 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 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
* [PATCH 1/4] gro: Name the GRO result enumeration type
From: Ben Hutchings @ 2009-10-29 17:17 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, netdev, linux-net-drivers
This clarifies which return and parameter types are GRO result codes
and not RX result codes.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/netdevice.h | 10 ++++++----
net/8021q/vlan_core.c | 5 +++--
net/core/dev.c | 12 +++++++-----
3 files changed, 16 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..421dc93 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;
@@ -2615,7 +2616,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;
--
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: Ben Hutchings @ 2009-10-29 17:12 UTC (permalink / raw)
To: Greg KH
Cc: Matt Domsch, Kay Sievers, dann frazier, linux-hotplug, Narendra_K,
netdev, Jordan_Hargrave, Charles_Rose
In-Reply-To: <20091029165556.GA9846@kroah.com>
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?
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: [Pv-drivers] [PATCH] vmxnet3: remove duplicate #include
From: Shreyas Bhatewara @ 2009-10-29 17:06 UTC (permalink / raw)
To: David Miller, Bhavesh Davda; +Cc: pv-drivers@vmware.com, netdev@vger.kernel.org
In-Reply-To: <20091029.065011.19666108.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, October 29, 2009 6:50 AM
> To: Bhavesh Davda
> Cc: Shreyas Bhatewara; pv-drivers@vmware.com; netdev@vger.kernel.org;
> weiyi.huang@gmail.com
> Subject: Re: [Pv-drivers] [PATCH] vmxnet3: remove duplicate #include
>
> From: Bhavesh Davda <bhavesh@vmware.com>
> Date: Thu, 29 Oct 2009 06:35:35 -0700
>
> > In other words, don't just trivially remove the X86 Kconfig
> > requirement for this driver.
>
> Then I assume you're going to add the endianness handling
> and send me a patch soon?
Yes, I will post a patch soon.
Thanks.
->Shreyas
^ permalink raw reply
* Re: [PATCH 2/3] net: TCP thin linear timeouts
From: Rick Jones @ 2009-10-29 17:01 UTC (permalink / raw)
To: Andreas Petlund
Cc: Ilpo Järvinen, Arnd Hannemann, Eric Dumazet, Netdev, LKML,
shemminger, David Miller
In-Reply-To: <58396856-6D7E-4CE1-8D66-D1F11205B0D5@simula.no>
Just how thin can a thin stream be when a thin stream is found thin? (to the
cadence of "How much wood could a woodchuck chuck if a woodchuck could chuck wood?")
Does a stream get so thin that a user's send could not be split into four,
sub-MSS TCP segments?
rick jones
^ permalink raw reply
* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: Greg KH @ 2009-10-29 16:55 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: <1256834975.2827.63.camel@achroite>
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.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/3] net: TCP thin linear timeouts
From: apetlund @ 2009-10-29 16:54 UTC (permalink / raw)
To: Arnd Hannemann
Cc: Andreas Petlund, Eric Dumazet, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, shemminger@vyatta.com,
ilpo.jarvinen@helsinki.fi, davem@davemloft.net
> Andreas Petlund schrieb:
>> We have found no noticeable degradation of the goodput in a series of
experiments we have performed in order to map the effects of the
modifications. Furthermore, the modifications implemented in the
patches
>> are explicitly enabled only for applications where the developer knows
that streams will be thin, thus only a small subset of the streams will
apply the modifications.
>> Graphs presenting results from experiments performed to analyse latency
and fairness issues can be found here:
>> http://folk.uio.no/apetlund/lktmp/
>
> How often did you hit consecutive RTOs in these measurements?
> As I see you did a measurement with 512 thick vs. 512 thin streams. Lets
do a hypothetical calculation with only 512 "thin" streams. Lets further
assume the rtt is low, so that RTO is around 200ms. Assume each segment
has 128 Bytes (already very small...).
> Assume after a period of normal operation all streams are in
> timeout-based loss recovery. (e.g. because destination endpoint
> suddenly behaves like a black hole)
> As all streams are in timeout-based loss recovery, each stream
> will transmit 5 segments each second with your modification.
> This would result in a throughput around 512*5*1024bit = 2560 kbit/s and
a goodput of 0 kbit/s (because the receiver is a black hole). So you can
easily saturate a 2 MBit/s link, only with retransmissions.
I have not yet performed experiments where the receiver becomes a black
hole, but I recognise the problem. Eric Dumazet suggested that the
mechanism switch to exponential backoff after 6 linear retries. This would
avoid situation where the link stays congested indefinitely, and I will
implement this in the next iteration.
> Unfortunately in Germany an ADSL uplink of 786 kbit/s is still quite
common, and its already called "broadband"...
I believe that a subscriber for such an uplink would not keep several
hundred thin-stream connections, though accidents do happen.
> Regarding the "small subset", why have a global sysctl option, then? And
I think "tcp_stream_is_thin(tp)" will be true for every flow in the RTO
case, at least for consecutive RTOs.
The sysctl is ment for cases of proprietary code that will benefit from
the modifications. In our experiments, we have found it useful in many
cases for such applications (like game clients).
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: Greg KH @ 2009-10-29 16:52 UTC (permalink / raw)
To: Narendra_K
Cc: Matt_Domsch, kay.sievers, dannf, linux-hotplug, netdev,
Jordan_Hargrave, Charles_Rose, bhutchings
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE589662@blrx3m08.blr.amer.dell.com>
On Thu, Oct 29, 2009 at 10:14:08PM +0530, Narendra_K@Dell.com 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.
>
> The interface name as assigned by the OS is determined by how the
> interface is named first during the OS installation.
That sounds like a distro install issue to me, why not fix it there?
> This name is made persistent by associating the name with it's MAC
> address in userspace, either by udev or ifcfg-eth files. In cases
> where there are one or more add-in cards along with one or more
> integrated cards (Lan on Motherboard), the integrated port 1, which is
> designated as Gb1 on the chassis may or may not get the name "eth0".
Exactly, who cares about "eth0" as a name?
> And that is the customer expectation, most of the times.
Then again, fix the installer to allow you to either pick the name, or
specify some rule in which to use to pick the name.
> Unattended installs and large scale image based installs are the most
> affected scenarios.
Then fix the installer.
> >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 is how the lspci tree view on a PER710 (PowerEdge R710) server with
> Four BCM5709 integrated NIC ports and One add-in Intel NIC port looks
> like. The integrated ports are always found before the add-in nic (or
> nics) by the BIOS consistently and BIOS guarantees it across every
> reboot.
Great, then you are set to write a udev rule for this, right?
> If the OS also found and named the network ports in the same manner,
> then there is no issue as integrated NIC port 1, designated Gb1 on the
> chassis, is always named as "eth0". But the observation is that, it is
> not the case always.
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.
> In such cases, pathnames like Embedded_NIC_1 -> eth[01..], point to the
> right interface, and communicate a more meaningful name without any
> state embedded in them.
Yes, pathnames would be nice to work for network devices, but
unfortunatly, that's just not how network devices work :)
thanks,
greg k-h
^ 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