* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-26 21:00 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.duyck, netdev
In-Reply-To: <1343324633.2626.11801.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 26 Jul 2012 19:43:53 +0200
> On Thu, 2012-07-26 at 19:36 +0200, Eric Dumazet wrote:
>> On Thu, 2012-07-26 at 19:31 +0200, Eric Dumazet wrote:
>> > On Thu, 2012-07-26 at 10:18 -0700, Alexander Duyck wrote:
>> >
>> > > I tested this patch and it looks like it runs, but still has the same
>> > > performance issue. I did some digging into the annotation for
>> > > ip_route_intput_noref and it seems like the issue is that I am hitting
>> > > the dst_hold call in __mkroute_input.
>> >
>> > David suggested a percpu cache.
>> >
>> > nh_rth_input would be allocated by alloc_percpu(struct dst *)
>> >
>> > I can work on this.
>>
>> Wait a minute, on input we should use the noref trick too.
>>
>
> Something like : (on top of latest David patch)
Grrr, I only got the local routes didn't I? :-)
That would explain everything.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-26 20:59 UTC (permalink / raw)
To: alexander.duyck; +Cc: eric.dumazet, netdev
In-Reply-To: <CAKgT0UfYEBYQOAoZ77rtwctbwau=2kx4rYdTyeaPaipeMUP9aw@mail.gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Thu, 26 Jul 2012 10:18:03 -0700
> I did some digging into the annotation for ip_route_intput_noref and
> it seems like the issue is that I am hitting the dst_hold call in
> __mkroute_input.
We shouldn't be building any routes in __mkroute_input except for the
very first packet, we should be instead using the cached route in the
FIB info nexthop.
Something's not right.
^ permalink raw reply
* Re: r8169, 3.5.0, does't work at all
From: Denys Fedoryshchenko @ 2012-07-26 20:44 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20120726195658.GA14668@electric-eye.fr.zoreil.com>
On 2012-07-26 22:56, Francois Romieu wrote:
> Denys Fedoryshchenko <denys@visp.net.lb> :
>> Just pushed new kernel to test cluster and got this:
> [...]
>> [ 1.606212] r8169 0000:03:00.0: eth1: RTL8168b/8111b at
>> 0xf8606000, 00:08:54:57:7a:33, XID 18000000 IRQ 44
>> [ 1.606366] r8169 0000:03:00.0: eth1: jumbo features [frames:
>> 4080 bytes, tx checksumming: ko]
>> ....
>> [ 20.406090] input device check on
>> [ 20.406177] Actions configured
>> [ 21.526836] r8169 0000:02:00.0: eth0: link up
>> [ 28.038386] ------------[ cut here ]------------
>> [ 28.038438] WARNING: at net/sched/sch_generic.c:255
>> dev_watchdog+0xd6/0x12a()
>> [ 28.038489] Hardware name:
>> [ 28.038534] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed
>
> Right at startup.
>
> Which kernel did you previously use ?
>
> This is exactly the primary device I use to access my test computer.
>
> .config and .dmesg will be welcome as well.
http://www.nuclearcat.com/dmesg.txt
http://www.nuclearcat.com/config.txt
There ifplugd also running, and udhcpc, both from busybox.
Now machine are deployed to production , working fine with 3.4.6
kernel. I can do limited tests on it,
and i can search for more machines with similar cards.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* Re: r8169, 3.5.0, does't work at all
From: Francois Romieu @ 2012-07-26 19:56 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <88f2e8e7f795239ec4bc759dcda61665@visp.net.lb>
Denys Fedoryshchenko <denys@visp.net.lb> :
> Just pushed new kernel to test cluster and got this:
[...]
> [ 1.606212] r8169 0000:03:00.0: eth1: RTL8168b/8111b at
> 0xf8606000, 00:08:54:57:7a:33, XID 18000000 IRQ 44
> [ 1.606366] r8169 0000:03:00.0: eth1: jumbo features [frames:
> 4080 bytes, tx checksumming: ko]
> ....
> [ 20.406090] input device check on
> [ 20.406177] Actions configured
> [ 21.526836] r8169 0000:02:00.0: eth0: link up
> [ 28.038386] ------------[ cut here ]------------
> [ 28.038438] WARNING: at net/sched/sch_generic.c:255
> dev_watchdog+0xd6/0x12a()
> [ 28.038489] Hardware name:
> [ 28.038534] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed
Right at startup.
Which kernel did you previously use ?
This is exactly the primary device I use to access my test computer.
.config and .dmesg will be welcome as well.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] vxge: Declare MODULE_FIRMWARE usage
From: Jon Mason @ 2012-07-26 19:55 UTC (permalink / raw)
To: Tim Gardner
Cc: linux-kernel, David S. Miller, Joe Perches, Jiri Pirko,
Stephen Hemminger, Paul Gortmaker, netdev
In-Reply-To: <1343329710-96747-1-git-send-email-tim.gardner@canonical.com>
On Thu, Jul 26, 2012 at 12:08 PM, Tim Gardner <tim.gardner@canonical.com> wrote:
> Cc: Jon Mason <jdmason@kudzu.us>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Joe Perches <joe@perches.com>
> Cc: Jiri Pirko <jpirko@redhat.com>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> ---
> drivers/net/ethernet/neterion/vxge/vxge-main.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/neterion/vxge/vxge-main.c b/drivers/net/ethernet/neterion/vxge/vxge-main.c
> index de21904..d4832b2 100644
> --- a/drivers/net/ethernet/neterion/vxge/vxge-main.c
> +++ b/drivers/net/ethernet/neterion/vxge/vxge-main.c
> @@ -4203,6 +4203,9 @@ out:
> return ret;
> }
>
> +#define VXGE_PXE_FIRMWARE "vxge/X3fw-pxe.ncf"
> +#define VXGE_FIRMWARE "vxge/X3fw.ncf"
> +
> static int vxge_probe_fw_update(struct vxgedev *vdev)
> {
> u32 maj, min, bld;
> @@ -4245,9 +4248,9 @@ static int vxge_probe_fw_update(struct vxgedev *vdev)
> }
> }
> if (gpxe)
> - fw_name = "vxge/X3fw-pxe.ncf";
> + fw_name = VXGE_PXE_FIRMWARE;
> else
> - fw_name = "vxge/X3fw.ncf";
> + fw_name = VXGE_FIRMWARE;
>
> ret = vxge_fw_upgrade(vdev, fw_name, 0);
> /* -EINVAL and -ENOENT are not fatal errors for flashing firmware on
> @@ -4855,3 +4858,5 @@ vxge_closer(void)
> }
> module_init(vxge_starter);
> module_exit(vxge_closer);
> +MODULE_FIRMWARE(VXGE_PXE_FIRMWARE);
> +MODULE_FIRMWARE(VXGE_FIRMWARE);
IIUC, MODULE_FIRMWARE is only necessary for devices that need firmware
to operate. vxge hardware has an image in flash on the nic, and the
modified code is used to update the firmware image on the adapter.
So, this change isn't doing what you want it to do.
Also, wasn't this already discussed (https://lkml.org/lkml/2012/4/12/401)?
Thanks,
Jon
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] vxge: Declare MODULE_FIRMWARE usage
From: Tim Gardner @ 2012-07-26 19:08 UTC (permalink / raw)
To: linux-kernel
Cc: Tim Gardner, Jon Mason, David S. Miller, Joe Perches, Jiri Pirko,
Stephen Hemminger, Paul Gortmaker, netdev
Cc: Jon Mason <jdmason@kudzu.us>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Joe Perches <joe@perches.com>
Cc: Jiri Pirko <jpirko@redhat.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
drivers/net/ethernet/neterion/vxge/vxge-main.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-main.c b/drivers/net/ethernet/neterion/vxge/vxge-main.c
index de21904..d4832b2 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-main.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-main.c
@@ -4203,6 +4203,9 @@ out:
return ret;
}
+#define VXGE_PXE_FIRMWARE "vxge/X3fw-pxe.ncf"
+#define VXGE_FIRMWARE "vxge/X3fw.ncf"
+
static int vxge_probe_fw_update(struct vxgedev *vdev)
{
u32 maj, min, bld;
@@ -4245,9 +4248,9 @@ static int vxge_probe_fw_update(struct vxgedev *vdev)
}
}
if (gpxe)
- fw_name = "vxge/X3fw-pxe.ncf";
+ fw_name = VXGE_PXE_FIRMWARE;
else
- fw_name = "vxge/X3fw.ncf";
+ fw_name = VXGE_FIRMWARE;
ret = vxge_fw_upgrade(vdev, fw_name, 0);
/* -EINVAL and -ENOENT are not fatal errors for flashing firmware on
@@ -4855,3 +4858,5 @@ vxge_closer(void)
}
module_init(vxge_starter);
module_exit(vxge_closer);
+MODULE_FIRMWARE(VXGE_PXE_FIRMWARE);
+MODULE_FIRMWARE(VXGE_FIRMWARE);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Alexander Duyck @ 2012-07-26 18:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1343324896.2626.11808.camel@edumazet-glaptop>
On Thu, Jul 26, 2012 at 10:48 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-07-26 at 19:43 +0200, Eric Dumazet wrote:
>> On Thu, 2012-07-26 at 19:36 +0200, Eric Dumazet wrote:
>> > On Thu, 2012-07-26 at 19:31 +0200, Eric Dumazet wrote:
>> > > On Thu, 2012-07-26 at 10:18 -0700, Alexander Duyck wrote:
>> > >
>> > > > I tested this patch and it looks like it runs, but still has the same
>> > > > performance issue. I did some digging into the annotation for
>> > > > ip_route_intput_noref and it seems like the issue is that I am hitting
>> > > > the dst_hold call in __mkroute_input.
>> > >
>> > > David suggested a percpu cache.
>> > >
>> > > nh_rth_input would be allocated by alloc_percpu(struct dst *)
>> > >
>> > > I can work on this.
>> >
>> > Wait a minute, on input we should use the noref trick too.
>> >
>>
>> Something like : (on top of latest David patch)
>
> Sorry updated patch : (missing skb_dst_set() before 'out' label)
The previous results were with a slight modifications to your earlier
patch. With this patch applied I am seeing 10.4Mpps with 8 queues,
reaching a maximum of 11.6Mpps with 9 queues.
When we have a final version for this patch let me know and I will
give it a quick run and throw in my tested by.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Alexander Duyck @ 2012-07-26 18:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1343324633.2626.11801.camel@edumazet-glaptop>
On Thu, Jul 26, 2012 at 10:43 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-07-26 at 19:36 +0200, Eric Dumazet wrote:
>> On Thu, 2012-07-26 at 19:31 +0200, Eric Dumazet wrote:
>> > On Thu, 2012-07-26 at 10:18 -0700, Alexander Duyck wrote:
>> >
>> > > I tested this patch and it looks like it runs, but still has the same
>> > > performance issue. I did some digging into the annotation for
>> > > ip_route_intput_noref and it seems like the issue is that I am hitting
>> > > the dst_hold call in __mkroute_input.
>> >
>> > David suggested a percpu cache.
>> >
>> > nh_rth_input would be allocated by alloc_percpu(struct dst *)
>> >
>> > I can work on this.
>>
>> Wait a minute, on input we should use the noref trick too.
>>
>
> Something like : (on top of latest David patch)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 7a591aa..d5d2ad1 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1371,8 +1371,7 @@ static void ip_handle_martian_source(struct net_device *dev,
> static int __mkroute_input(struct sk_buff *skb,
> const struct fib_result *res,
> struct in_device *in_dev,
> - __be32 daddr, __be32 saddr, u32 tos,
> - struct rtable **result)
> + __be32 daddr, __be32 saddr, u32 tos)
> {
> struct rtable *rth;
> int err;
> @@ -1423,7 +1422,7 @@ static int __mkroute_input(struct sk_buff *skb,
> if (!itag) {
> rth = FIB_RES_NH(*res).nh_rth_input;
> if (rt_cache_valid(rth)) {
> - dst_hold(&rth->dst);
> + skb_dst_set_noref(skb, &rth->dst);
> goto out;
> }
> do_cache = true;
> @@ -1451,7 +1450,6 @@ static int __mkroute_input(struct sk_buff *skb,
>
> rt_set_nexthop(rth, daddr, res, NULL, res->fi, res->type, itag);
> out:
> - *result = rth;
> err = 0;
> cleanup:
> return err;
> @@ -1463,21 +1461,13 @@ static int ip_mkroute_input(struct sk_buff *skb,
> struct in_device *in_dev,
> __be32 daddr, __be32 saddr, u32 tos)
> {
> - struct rtable *rth = NULL;
> - int err;
> -
> #ifdef CONFIG_IP_ROUTE_MULTIPATH
> if (res->fi && res->fi->fib_nhs > 1)
> fib_select_multipath(res);
> #endif
>
> /* create a routing cache entry */
> - err = __mkroute_input(skb, res, in_dev, daddr, saddr, tos, &rth);
> - if (err)
> - return err;
> -
> - skb_dst_set(skb, &rth->dst);
> - return 0;
> + return __mkroute_input(skb, res, in_dev, daddr, saddr, tos);
> }
>
> /*
>
With your changes in place I see an increase from 7.5Mpps to 9.9Mpps
for 8 queues, and increasing the queues to 9 gets me up to 11Mpps even
if the 9th queue is on another node. This is a HUGE improvement over
what we had before.
The only remaining overhead that has been introduced with the recent
changes appears to be the fib_table_lookup which doesn't have any hot
spots that jump out at me. The performance is in-line with what I was
seeing when I was randomly generating source IPs from a fairly large
set so I suspect this is just the expected behaviour without a routing
cache in place.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-26 17:48 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, netdev
In-Reply-To: <1343324633.2626.11801.camel@edumazet-glaptop>
On Thu, 2012-07-26 at 19:43 +0200, Eric Dumazet wrote:
> On Thu, 2012-07-26 at 19:36 +0200, Eric Dumazet wrote:
> > On Thu, 2012-07-26 at 19:31 +0200, Eric Dumazet wrote:
> > > On Thu, 2012-07-26 at 10:18 -0700, Alexander Duyck wrote:
> > >
> > > > I tested this patch and it looks like it runs, but still has the same
> > > > performance issue. I did some digging into the annotation for
> > > > ip_route_intput_noref and it seems like the issue is that I am hitting
> > > > the dst_hold call in __mkroute_input.
> > >
> > > David suggested a percpu cache.
> > >
> > > nh_rth_input would be allocated by alloc_percpu(struct dst *)
> > >
> > > I can work on this.
> >
> > Wait a minute, on input we should use the noref trick too.
> >
>
> Something like : (on top of latest David patch)
Sorry updated patch : (missing skb_dst_set() before 'out' label)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 7a591aa..fc1a81c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1371,8 +1371,7 @@ static void ip_handle_martian_source(struct net_device *dev,
static int __mkroute_input(struct sk_buff *skb,
const struct fib_result *res,
struct in_device *in_dev,
- __be32 daddr, __be32 saddr, u32 tos,
- struct rtable **result)
+ __be32 daddr, __be32 saddr, u32 tos)
{
struct rtable *rth;
int err;
@@ -1423,7 +1422,7 @@ static int __mkroute_input(struct sk_buff *skb,
if (!itag) {
rth = FIB_RES_NH(*res).nh_rth_input;
if (rt_cache_valid(rth)) {
- dst_hold(&rth->dst);
+ skb_dst_set_noref(skb, &rth->dst);
goto out;
}
do_cache = true;
@@ -1450,8 +1449,8 @@ static int __mkroute_input(struct sk_buff *skb,
rth->dst.output = ip_output;
rt_set_nexthop(rth, daddr, res, NULL, res->fi, res->type, itag);
+ skb_dst_set(skb, &rth->dst);
out:
- *result = rth;
err = 0;
cleanup:
return err;
@@ -1463,21 +1462,13 @@ static int ip_mkroute_input(struct sk_buff *skb,
struct in_device *in_dev,
__be32 daddr, __be32 saddr, u32 tos)
{
- struct rtable *rth = NULL;
- int err;
-
#ifdef CONFIG_IP_ROUTE_MULTIPATH
if (res->fi && res->fi->fib_nhs > 1)
fib_select_multipath(res);
#endif
/* create a routing cache entry */
- err = __mkroute_input(skb, res, in_dev, daddr, saddr, tos, &rth);
- if (err)
- return err;
-
- skb_dst_set(skb, &rth->dst);
- return 0;
+ return __mkroute_input(skb, res, in_dev, daddr, saddr, tos);
}
/*
^ permalink raw reply related
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-26 17:43 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, netdev
In-Reply-To: <1343324175.2626.11790.camel@edumazet-glaptop>
On Thu, 2012-07-26 at 19:36 +0200, Eric Dumazet wrote:
> On Thu, 2012-07-26 at 19:31 +0200, Eric Dumazet wrote:
> > On Thu, 2012-07-26 at 10:18 -0700, Alexander Duyck wrote:
> >
> > > I tested this patch and it looks like it runs, but still has the same
> > > performance issue. I did some digging into the annotation for
> > > ip_route_intput_noref and it seems like the issue is that I am hitting
> > > the dst_hold call in __mkroute_input.
> >
> > David suggested a percpu cache.
> >
> > nh_rth_input would be allocated by alloc_percpu(struct dst *)
> >
> > I can work on this.
>
> Wait a minute, on input we should use the noref trick too.
>
Something like : (on top of latest David patch)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 7a591aa..d5d2ad1 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1371,8 +1371,7 @@ static void ip_handle_martian_source(struct net_device *dev,
static int __mkroute_input(struct sk_buff *skb,
const struct fib_result *res,
struct in_device *in_dev,
- __be32 daddr, __be32 saddr, u32 tos,
- struct rtable **result)
+ __be32 daddr, __be32 saddr, u32 tos)
{
struct rtable *rth;
int err;
@@ -1423,7 +1422,7 @@ static int __mkroute_input(struct sk_buff *skb,
if (!itag) {
rth = FIB_RES_NH(*res).nh_rth_input;
if (rt_cache_valid(rth)) {
- dst_hold(&rth->dst);
+ skb_dst_set_noref(skb, &rth->dst);
goto out;
}
do_cache = true;
@@ -1451,7 +1450,6 @@ static int __mkroute_input(struct sk_buff *skb,
rt_set_nexthop(rth, daddr, res, NULL, res->fi, res->type, itag);
out:
- *result = rth;
err = 0;
cleanup:
return err;
@@ -1463,21 +1461,13 @@ static int ip_mkroute_input(struct sk_buff *skb,
struct in_device *in_dev,
__be32 daddr, __be32 saddr, u32 tos)
{
- struct rtable *rth = NULL;
- int err;
-
#ifdef CONFIG_IP_ROUTE_MULTIPATH
if (res->fi && res->fi->fib_nhs > 1)
fib_select_multipath(res);
#endif
/* create a routing cache entry */
- err = __mkroute_input(skb, res, in_dev, daddr, saddr, tos, &rth);
- if (err)
- return err;
-
- skb_dst_set(skb, &rth->dst);
- return 0;
+ return __mkroute_input(skb, res, in_dev, daddr, saddr, tos);
}
/*
^ permalink raw reply related
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-26 17:36 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, netdev
In-Reply-To: <1343323858.2626.11783.camel@edumazet-glaptop>
On Thu, 2012-07-26 at 19:31 +0200, Eric Dumazet wrote:
> On Thu, 2012-07-26 at 10:18 -0700, Alexander Duyck wrote:
>
> > I tested this patch and it looks like it runs, but still has the same
> > performance issue. I did some digging into the annotation for
> > ip_route_intput_noref and it seems like the issue is that I am hitting
> > the dst_hold call in __mkroute_input.
>
> David suggested a percpu cache.
>
> nh_rth_input would be allocated by alloc_percpu(struct dst *)
>
> I can work on this.
Wait a minute, on input we should use the noref trick too.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-26 17:30 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, netdev
In-Reply-To: <CAKgT0UfYEBYQOAoZ77rtwctbwau=2kx4rYdTyeaPaipeMUP9aw@mail.gmail.com>
On Thu, 2012-07-26 at 10:18 -0700, Alexander Duyck wrote:
> I tested this patch and it looks like it runs, but still has the same
> performance issue. I did some digging into the annotation for
> ip_route_intput_noref and it seems like the issue is that I am hitting
> the dst_hold call in __mkroute_input.
David suggested a percpu cache.
nh_rth_input would be allocated by alloc_percpu(struct dst *)
I can work on this.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Alexander Duyck @ 2012-07-26 17:18 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20120726.014736.1066206957795563053.davem@davemloft.net>
On Thu, Jul 26, 2012 at 1:47 AM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 26 Jul 2012 10:27:58 +0200
>
>> But isnt DST_NOCACHE intent reverted then ?
>>
>> like you meant :
>>
>> + } else {
>> + /* Routes we intend to cache in the FIB nexthop have
>> + * the DST_NOCACHE bit unset. However, if we are
>> + * unsuccessful at storing this route into the cache
>> + * we really need to set that bit.
>> + */
>> + rt->dst.flags |= DST_NOCACHE;
>> }
>
> Indeed, thanks for catching this bug.
>
> Here's a new version of the patch, as I found another error. In
> fib_semantics.c, we have to change dst_release() to dst_free() for the
> liberation the nexthop cached routes.
I tested this patch and it looks like it runs, but still has the same
performance issue. I did some digging into the annotation for
ip_route_intput_noref and it seems like the issue is that I am hitting
the dst_hold call in __mkroute_input.
You were correct about the ARP entry. It looks like I had messed up
my test script and it wasn't putting the static ARP entry back in.
I'm amazed it was even working since my SmartBits system doesn't
normally even reply to ARPs.
Thanks,
Alex
^ permalink raw reply
* Re: open sockets preventing unregister_netdevice from completing in linux-next (next-20120724)
From: Eric Dumazet @ 2012-07-26 17:15 UTC (permalink / raw)
To: David Miller; +Cc: bjorn, netdev
In-Reply-To: <20120725.151737.1807149851147342859.davem@davemloft.net>
On Wed, 2012-07-25 at 15:17 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 25 Jul 2012 16:38:48 +0200
>
> > Yes, we miss what was done with rt_cache_flush() : find all cached
> > routes and release all dev references...
>
> We can fix this with a two-pronged approach:
>
> 1) Walk the FIB info nexthops and invalidate.
>
> 2) Entries not cached in the FIB info nexthops go into a
> per-netns list which is scanned as well.
>
> I'll try to work on this if nobody beats me to it.
With your latest patch, I can "rmmod tg3" while sockets are active.
Not sure we need all this now ?
(the trick is probably in fib_semantics.c, when you changed
dst_release() to dst_free())
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-26 17:02 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: David Miller, netdev
In-Reply-To: <500D8FEE.7050802@itcare.pl>
On Mon, 2012-07-23 at 19:54 +0200, Paweł Staszewski wrote:
> I make some real life tests with 10Gbit traffic and make some rdos.
> With kernel 3.4.5 when I reach 6M routing cache entries - traffic is not
> forwarded - on my hardware with 64G RAM
>
> With kernel - 3.5.0-rc7-next-20120720 + David M. patches - route cache
> removal + fix
> Traffic is forwarder all the time at speed 8.2Mpps RX from traffic
> generator and 8.2Mpps TX to the sink
>
> Also I see performance improvement.
>
> With kernel 3.4.5 I can reach maximum od 7.5Mpps with my hardware
> And with kernel 3.5.0-rc7-next-20120720 i can reach 8.2Mpps - forwarding
> UDP performance - can be more - but my TX pktgen that use 6 cores can't
> do more.
>
> Really thanks for this :)
In real life, with TCP traffic, make sure you
set /proc/sys/net/ipv4/ip_early_demux to 0
^ permalink raw reply
* Re: [RFC ETHTOOL PATCH 2/2] ethtool: allow setting MDI-X state
From: Ben Hutchings @ 2012-07-26 16:35 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <20120726163033.GA20122@jbrandeb-snb.jf.intel.com>
On Thu, 2012-07-26 at 09:30 -0700, Jesse Brandeburg wrote:
> On Wed, Jul 25, 2012 at 11:59:02PM +0100, Ben Hutchings wrote:
> > On Wed, 2012-07-25 at 10:53 -0700, Jesse Brandeburg wrote:
> > How about when you have a forced mode but the driver reports eth_tp_mdix
> > = ETH_TP_MDI_INVALID because the link is down? This is going to result
> > in:
> >
> > MDI-X: Unknown (forced)
> >
> > which makes no sense at all. So I think that we have to do something
> > like:
> >
> > if (ep->eth_tp_mdix_ctrl == ETH_TP_MDI) {
> > fprintf(stdout, "off (forced)\n");
> > } else if (ep->eth_tp_mdix_ctrl == ETH_TP_MDI_X) {
> > fprintf(stdout, "on (forced)\n");
> > } else {
> > switch (ep->eth_tp_mdix) {
> > ...
> > }
> > if (ep->eth_tp_mdix_ctrl == ETH_TP_MDI_AUTO)
> > fprintf(stdout, " (auto)");
> > fprintf(stdout, "\n");
> > }
> >
> > Or else we require that when the mode is forced then drivers report that
> > as the current status even if the link is down.
>
> I tried that and it works swimmingly. How does this look?
[...]
That looks good, thanks.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
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] iproute: Add route showdump command
From: Stephen Hemminger @ 2012-07-26 16:03 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Dan Smith, Linux Netdev List
In-Reply-To: <50110593.1070502@parallels.com>
On Thu, 26 Jul 2012 12:53:39 +0400
Pavel Emelyanov <xemul@parallels.com> wrote:
> Some time ago the save+restore commands were added to ip route (git
> id f4ff11e3, Add ip route save/restore). These two save the raw rtnl
> stream into a file and restore one (reading it from stdin).
>
> The problem is that there's no way to get the contents of the dump
> file in a human readable form. How about adding a command that reads
> the rtnl stream from stdin and prints the data in a way the usual
> "ip route list" does?
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Being able to decode a dump is great idea.
Are the user's smart enough not to try it out at the command prompt
and get totally lost? Maybe another isatty() check is needed.
Another solution would be to put a small header on the save file with
a magic number that could be checked. This would mean changing save/restore/showdump
and ideally updating the magic file in distributions.
^ permalink raw reply
* [PATCH 3/3] pch_gbe: vlan skb len fix
From: Andy Cress @ 2012-07-26 16:01 UTC (permalink / raw)
To: netdev
pch_gbe_xmit_frame skb->len verification was incorrect in vlan case
causing bogus transfer length errors. One correction could be:
offset = skb->protocol == htons(ETH_P_8021Q) ? 0 : 4;
if (unlikely(skb->len > (adapter->hw.mac.max_frame_size - offset)))
However, this verification is not necessary, so remove it.
Signed-off-by: Andy Cress <andy.cress@us.kontron.com>
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 000ef68..817614c 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -2157,13 +2157,6 @@ static int pch_gbe_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
struct pch_gbe_tx_ring *tx_ring = adapter->tx_ring;
unsigned long flags;
- if (unlikely(skb->len > (adapter->hw.mac.max_frame_size - 4))) {
- pr_err("Transfer length Error: skb len: %d > max: %d\n",
- skb->len, adapter->hw.mac.max_frame_size);
- dev_kfree_skb_any(skb);
- adapter->stats.tx_length_errors++;
- return NETDEV_TX_OK;
- }
if (!spin_trylock_irqsave(&tx_ring->tx_lock, flags)) {
/* Collision - tell upper layer to requeue */
return NETDEV_TX_LOCKED;
^ permalink raw reply related
* [PATCH 2/3] pch_gbe: add extra clean tx
From: Andy Cress @ 2012-07-26 16:00 UTC (permalink / raw)
To: netdev
This adds extra cleaning to the pch_gbe_clean_tx routine to avoid
transmit timeouts on some BCM PHYs that have different timing.
Also update the DRV_VERSION to 1.01, and show it.
Signed-off-by: Andy Cress <andy.cress@us.kontron.com>
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 8694704..000ef68 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -26,7 +26,7 @@
#include <linux/ptp_classify.h>
#endif
-#define DRV_VERSION "1.00"
+#define DRV_VERSION "1.01"
const char pch_driver_version[] = DRV_VERSION;
#define PCI_DEVICE_ID_INTEL_IOH1_GBE 0x8802 /* Pci device ID */
@@ -1579,7 +1579,8 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
struct sk_buff *skb;
unsigned int i;
unsigned int cleaned_count = 0;
- bool cleaned = true;
+ bool cleaned = false;
+ int unused, thresh;
pr_debug("next_to_clean : %d\n", tx_ring->next_to_clean);
@@ -1588,10 +1589,36 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
pr_debug("gbec_status:0x%04x dma_status:0x%04x\n",
tx_desc->gbec_status, tx_desc->dma_status);
+ unused = PCH_GBE_DESC_UNUSED(tx_ring);
+ thresh = tx_ring->count - PCH_GBE_TX_WEIGHT;
+ if ((tx_desc->gbec_status == DSC_INIT16) && (unused < thresh))
+ { /* current marked clean, tx queue filling up, do extra clean */
+ int j, k;
+ if (unused < 8) { /* tx queue nearly full */
+ pr_debug("clean_tx: transmit queue warning (%x,%x) unused=%d\n",
+ tx_ring->next_to_clean,tx_ring->next_to_use,unused);
+ }
+
+ /* current marked clean, scan for more that need cleaning. */
+ k = i;
+ for (j = 0; j < PCH_GBE_TX_WEIGHT; j++)
+ {
+ tx_desc = PCH_GBE_TX_DESC(*tx_ring, k);
+ if (tx_desc->gbec_status != DSC_INIT16) break; /*found*/
+ if (++k >= tx_ring->count) k = 0; /*increment, wrap*/
+ }
+ if (j < PCH_GBE_TX_WEIGHT) {
+ pr_debug("clean_tx: unused=%d loops=%d found tx_desc[%x,%x:%x].gbec_status=%04x\n",
+ unused,j, i,k, tx_ring->next_to_use, tx_desc->gbec_status);
+ i = k; /*found one to clean, usu gbec_status==2000.*/
+ }
+ }
+
while ((tx_desc->gbec_status & DSC_INIT16) == 0x0000) {
pr_debug("gbec_status:0x%04x\n", tx_desc->gbec_status);
buffer_info = &tx_ring->buffer_info[i];
skb = buffer_info->skb;
+ cleaned = true;
if ((tx_desc->gbec_status & PCH_GBE_TXD_GMAC_STAT_ABT)) {
adapter->stats.tx_aborted_errors++;
@@ -1639,18 +1666,21 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
}
pr_debug("called pch_gbe_unmap_and_free_tx_resource() %d count\n",
cleaned_count);
- /* Recover from running out of Tx resources in xmit_frame */
- spin_lock(&tx_ring->tx_lock);
- if (unlikely(cleaned && (netif_queue_stopped(adapter->netdev)))) {
- netif_wake_queue(adapter->netdev);
- adapter->stats.tx_restart_count++;
- pr_debug("Tx wake queue\n");
- }
+ if (cleaned_count > 0) { /*skip this if nothing cleaned*/
+ /* Recover from running out of Tx resources in xmit_frame */
+ spin_lock(&tx_ring->tx_lock);
+ if (unlikely(cleaned && (netif_queue_stopped(adapter->netdev))))
+ {
+ netif_wake_queue(adapter->netdev);
+ adapter->stats.tx_restart_count++;
+ pr_debug("Tx wake queue\n");
+ }
- tx_ring->next_to_clean = i;
+ tx_ring->next_to_clean = i;
- pr_debug("next_to_clean : %d\n", tx_ring->next_to_clean);
- spin_unlock(&tx_ring->tx_lock);
+ pr_debug("next_to_clean : %d\n", tx_ring->next_to_clean);
+ spin_unlock(&tx_ring->tx_lock);
+ }
return cleaned;
}
@@ -2387,7 +2417,7 @@ static int pch_gbe_napi_poll(struct napi_struct *napi, int budget)
pch_gbe_clean_rx(adapter, adapter->rx_ring, &work_done, budget);
cleaned = pch_gbe_clean_tx(adapter, adapter->tx_ring);
- if (!cleaned)
+ if (cleaned)
work_done = budget;
/* If no Tx and not enough Rx work done,
* exit the polling mode
@@ -2793,6 +2823,7 @@ static int __init pch_gbe_init_module(void)
{
int ret;
+ pr_info("EG20T PCH Gigabit Ethernet Driver - version %s\n",DRV_VERSION);
ret = pci_register_driver(&pch_gbe_driver);
if (copybreak != PCH_GBE_COPYBREAK_DEFAULT) {
if (copybreak == 0) {
^ permalink raw reply related
* [PATCH 1/3] pch_gbe: fix transmit watchdog timeout
From: Andy Cress @ 2012-07-26 15:59 UTC (permalink / raw)
To: netdev
An extended ping test with 6 vlans resulted in a driver oops with a
netdev transmit timeout.
Fix WATCHDOG_TIMEOUT to be more like e1000e at 5 * HZ, to avoid
unnecessary transmit timeouts.
Signed-off-by: Andy Cress <andy.cress@us.kontron.com>
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 4c04843..a746064 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -35,7 +35,7 @@ const char pch_driver_version[] = DRV_VERSION;
#define DSC_INIT16 0xC000
#define PCH_GBE_DMA_ALIGN 0
#define PCH_GBE_DMA_PADDING 2
-#define PCH_GBE_WATCHDOG_PERIOD (1 * HZ) /* watchdog time */
+#define PCH_GBE_WATCHDOG_PERIOD (5 * HZ) /* watchdog time */
#define PCH_GBE_COPYBREAK_DEFAULT 256
#define PCH_GBE_PCI_BAR 1
#define PCH_GBE_RESERVE_MEMORY 0x200000 /* 2MB */
^ permalink raw reply related
* [PATCH 0/4] pch_gbe: avoiding transmit timeouts (rev3)
From: Andy Cress @ 2012-07-26 15:57 UTC (permalink / raw)
To: netdev
When the interface is stressed with 6 VLANs, some transmit timeout stats were
observed, which is a potential precursor to the more severe netdev watchdog
timeout oops. Also we saw more than the expected number of transmit restarts, which impacted performance. The following patches were applied and resolved
the symptom of the transmit timeout stats, and reduced the number of
transmit restarts.
This patch set includes the following patches:
0001-pch_gbe-fix-transmit-watchdog-timeout.patch
0002-pch_gbe-add-extra-clean-tx.patch (includes bumping the version to 1.01)
0003-pch_gbe-vlan-skb-len-fix.patch
This rev3 has the following changes:
* Removed Fix-the-checksum-fill-to-the-error-location.patch for now so Hongbo can evaluate/revise/test based on feedback.
The resulting pch_gbe 1.01 driver has been tested on Kontron Tunnel Creek
EG20T modules and Intel Crown Bay EG20T modules, so I believe that these are
appropriate for consideration in the upstream pch_gbe driver.
Please review and comment.
Thanks,
Andy
^ permalink raw reply
* Premature timeout for MLDv1 Host compatibility mode?
From: Dragos Ilie @ 2012-07-26 14:57 UTC (permalink / raw)
To: netdev
Hi!
I suspect that the MLDv1 Host compatibility mode is ended prematurely.
In net/ipv6/mcast.c the "Older Version Querier Present" timeout is
computed as
max_delay = (ntohs(mld->mld_maxdelay)*HZ)/1000;
switchback = (idev->mc_qrv + 1) * max_delay;
idev->mc_v1_seen = jiffies + switchback;
RFC 3810 says that the timeout should be computed as
Robustness_Variable * Query_Interval + Query_Response_Interval. This
suggests that the line where switchback is computed should be changed
to something like
switchback = (idev->mc_qrv * 125 * HZ) + max_delay;
where 125 is the default Query_Interval in seconds
I would appreciate it if somebody can confirm if my suspicion is correct.
Regards,
Dragos
^ permalink raw reply
* Re: [PATCH]net:appletalk:ddp:fixed coding style issue in net/appletalk/ddp.c
From: Joe Perches @ 2012-07-26 14:11 UTC (permalink / raw)
To: Jeffrin Jose; +Cc: acme, davem, netdev, linux-kernel
In-Reply-To: <1343311142-4539-1-git-send-email-ahiliation@yahoo.co.in>
On Thu, 2012-07-26 at 19:29 +0530, Jeffrin Jose wrote:
> Fixed coding style issue relating to switch and case
> statement in file net/appletalk/ddp.c
Don't just move the case labels, move the code blocks
including comments.
> diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
[]
> @@ -1798,7 +1798,7 @@ static int atalk_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
>
> switch (cmd) {
> /* Protocol layer */
> - case TIOCOUTQ: {
> + case TIOCOUTQ: {
> long amount = sk->sk_sndbuf - sk_wmem_alloc_get(sk);
long amount = etc...
Post the patch with a commit message that says that
that a git diff -w is empty and the compiled objects
are the same too.
^ permalink raw reply
* [PATCH]net:appletalk:ddp:fixed coding style issue in net/appletalk/ddp.c
From: Jeffrin Jose @ 2012-07-26 13:59 UTC (permalink / raw)
To: acme, davem; +Cc: netdev, linux-kernel, ahiliation
Fixed coding style issue relating to switch and case
statement in file net/appletalk/ddp.c
Signed-off-by: Jeffrin Jose <ahiliation@yahoo.co.in>
---
net/appletalk/ddp.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index 0301b32..c8bbcd2 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -1798,7 +1798,7 @@ static int atalk_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
switch (cmd) {
/* Protocol layer */
- case TIOCOUTQ: {
+ case TIOCOUTQ: {
long amount = sk->sk_sndbuf - sk_wmem_alloc_get(sk);
if (amount < 0)
@@ -1806,7 +1806,7 @@ static int atalk_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
rc = put_user(amount, (int __user *)argp);
break;
}
- case TIOCINQ: {
+ case TIOCINQ: {
/*
* These two are safe on a single CPU system as only
* user tasks fiddle here
@@ -1819,27 +1819,27 @@ static int atalk_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
rc = put_user(amount, (int __user *)argp);
break;
}
- case SIOCGSTAMP:
+ case SIOCGSTAMP:
rc = sock_get_timestamp(sk, argp);
break;
- case SIOCGSTAMPNS:
+ case SIOCGSTAMPNS:
rc = sock_get_timestampns(sk, argp);
break;
/* Routing */
- case SIOCADDRT:
- case SIOCDELRT:
+ case SIOCADDRT:
+ case SIOCDELRT:
rc = -EPERM;
if (capable(CAP_NET_ADMIN))
rc = atrtr_ioctl(cmd, argp);
break;
/* Interface */
- case SIOCGIFADDR:
- case SIOCSIFADDR:
- case SIOCGIFBRDADDR:
- case SIOCATALKDIFADDR:
- case SIOCDIFADDR:
- case SIOCSARP: /* proxy AARP */
- case SIOCDARP: /* proxy AARP */
+ case SIOCGIFADDR:
+ case SIOCSIFADDR:
+ case SIOCGIFBRDADDR:
+ case SIOCATALKDIFADDR:
+ case SIOCDIFADDR:
+ case SIOCSARP: /* proxy AARP */
+ case SIOCDARP: /* proxy AARP */
rtnl_lock();
rc = atif_ioctl(cmd, argp);
rtnl_unlock();
--
1.7.10
^ permalink raw reply related
* Re: [PATCH RESEND 0/9] OLPC: create a generic OLPC EC driver
From: Thomas Gleixner @ 2012-07-26 13:51 UTC (permalink / raw)
To: Andres Salomon
Cc: Andrew Morton, Paul Fox, Daniel Drake, Richard A. Smith,
linux-kernel, libertas-dev, linux-wireless, netdev,
platform-driver-x86, devel, Ingo Molnar, H. Peter Anvin, x86,
Dan Williams, John W. Linville, Matthew Garrett, Anton Vorontsov,
David Woodhouse, Chris Ball, Jon Nettleton, Greg Kroah-Hartman
In-Reply-To: <20120718213713.232e4161@dev.queued.net>
On Wed, 18 Jul 2012, Andres Salomon wrote:
> The OLPC EC (Embedded Controller) code that is currently upstream is
> x86-only, originally written for the XO-1. Since then, we've had the
> XO-1.5 (also x86), and XO-1.75 (arm-based) enter mass production. The
> 1.75 uses a vastly different EC protocol, and future hardware revisions
> are likely to change it even further.
>
> However, the drivers do share quite a bit of code, so it makes sense to
> have a platform-agnostic driver that calls into platform-specific hooks
> for each XO's EC driver. This is the first stab and creating such a
> beast (with further patches pending). Aside from the lack of code
> duplication, this is helpful for fixing bugs in one place (for example,
> we fixed an EC suspend/resume bug in 1.75 that I've just seen happen on
> 1.5 without these patches. With these patches, the problem goes away).
>
> These patches are against Linus's current HEAD; let me know if they
> don't apply somewhere, and I'll happily redo them against the -next
> tree. I'm assuming that these changes (which touch places like x86,
> wireless, and staging) should go through either the x86 tree, or
> through akpm's tree.
>
> Alternatively, if the reviews are positive and I can get SOBs from the
> relevant maintainers, I can set up a platform-olpc tree somewhere and
> request a pull from Linus.
Either via akpm or a separate tree are fine with me.
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ 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