* [PATCH 2/2] iproute: Add route showdump command (v2)
From: Pavel Emelyanov @ 2012-07-27 4:57 UTC (permalink / raw)
To: Stephen Hemminger, Linux Netdev List
In-Reply-To: <50121F4D.8090606@parallels.com>
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. The proposal is to add a command that
reads the rtnl stream from stdin and prints the data in a way the
usual "ip route list" does?
changes since v1:
* Take the magic at the beginning of the dump file into account
* Check for stdin (the dump is taken from) is not a tty
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
ip/iproute.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index bbb3923..572e2e8 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -60,6 +60,7 @@ static void usage(void)
fprintf(stderr, "Usage: ip route { list | flush } SELECTOR\n");
fprintf(stderr, " ip route save SELECTOR\n");
fprintf(stderr, " ip route restore\n");
+ fprintf(stderr, " ip route showdump\n");
fprintf(stderr, " ip route get ADDRESS [ from ADDRESS iif STRING ]\n");
fprintf(stderr, " [ oif STRING ] [ tos TOS ]\n");
fprintf(stderr, " [ mark NUMBER ]\n");
@@ -1566,6 +1567,20 @@ int iproute_restore(void)
exit(rtnl_from_file(stdin, &restore_handler, NULL));
}
+static int show_handler(const struct sockaddr_nl *nl, struct nlmsghdr *n, void *arg)
+{
+ print_route(nl, n, stdout);
+ return 0;
+}
+
+static int iproute_showdump(void)
+{
+ if (route_dump_check_magic())
+ exit(-1);
+
+ exit(rtnl_from_file(stdin, &show_handler, NULL));
+}
+
void iproute_reset_filter()
{
memset(&filter, 0, sizeof(filter));
@@ -1610,6 +1625,8 @@ int do_iproute(int argc, char **argv)
return iproute_list_flush_or_save(argc-1, argv+1, IPROUTE_SAVE);
if (matches(*argv, "restore") == 0)
return iproute_restore();
+ if (matches(*argv, "showdump") == 0)
+ return iproute_showdump();
if (matches(*argv, "help") == 0)
usage();
fprintf(stderr, "Command \"%s\" is unknown, try \"ip route help\".\n", *argv);
--
1.5.5.6
^ permalink raw reply related
* [PATCH 1/2] iproute: Add magic cookie to route dump file
From: Pavel Emelyanov @ 2012-07-27 4:55 UTC (permalink / raw)
To: Stephen Hemminger, Linux Netdev List
In order to somehow verify that a blob contains route dump a
4-bytes magic is put at the head of the data and is checked
on restore.
Magic digits are taken from Portland (OR) coordinates :) Is
there any more reliable way of generating such?
Signed-of-by: Pavel Emelyanov <xemul@parallels.com>
---
ip/iproute.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index 5cd313e..bbb3923 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -1064,6 +1064,8 @@ static int iproute_flush_cache(void)
return 0;
}
+static __u32 route_dump_magic = 0x45311224;
+
int save_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
{
int ret;
@@ -1072,11 +1074,6 @@ int save_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
struct rtattr *tb[RTA_MAX+1];
int host_len = -1;
- if (isatty(STDOUT_FILENO)) {
- fprintf(stderr, "Not sending binary stream to stdout\n");
- return -1;
- }
-
host_len = calc_host_len(r);
len -= NLMSG_LENGTH(sizeof(*r));
parse_rtattr(tb, RTA_MAX, RTM_RTA(r), len);
@@ -1093,6 +1090,24 @@ int save_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
return ret == n->nlmsg_len ? 0 : ret;
}
+static int save_route_prep(void)
+{
+ int ret;
+
+ if (isatty(STDOUT_FILENO)) {
+ fprintf(stderr, "Not sending binary stream to stdout\n");
+ return -1;
+ }
+
+ ret = write(STDOUT_FILENO, &route_dump_magic, sizeof(route_dump_magic));
+ if (ret != sizeof(route_dump_magic)) {
+ fprintf(stderr, "Can't write magic to dump file\n");
+ return -1;
+ }
+
+ return 0;
+}
+
static int iproute_list_flush_or_save(int argc, char **argv, int action)
{
int do_ipv6 = preferred_family;
@@ -1101,9 +1116,12 @@ static int iproute_list_flush_or_save(int argc, char **argv, int action)
unsigned int mark = 0;
rtnl_filter_t filter_fn;
- if (action == IPROUTE_SAVE)
+ if (action == IPROUTE_SAVE) {
+ if (save_route_prep())
+ return -1;
+
filter_fn = save_route;
- else
+ } else
filter_fn = print_route;
iproute_reset_filter();
@@ -1521,8 +1539,30 @@ int restore_handler(const struct sockaddr_nl *nl, struct nlmsghdr *n, void *arg)
return ret;
}
+static int route_dump_check_magic(void)
+{
+ int ret;
+ __u32 magic = 0;
+
+ if (isatty(STDIN_FILENO)) {
+ fprintf(stderr, "Can't restore route dump from a terminal\n");
+ return -1;
+ }
+
+ ret = fread(&magic, sizeof(magic), 1, stdin);
+ if (magic != route_dump_magic) {
+ fprintf(stderr, "Magic mismatch (%d elems, %x magic)\n", ret, magic);
+ return -1;
+ }
+
+ return 0;
+}
+
int iproute_restore(void)
{
+ if (route_dump_check_magic())
+ exit(-1);
+
exit(rtnl_from_file(stdin, &restore_handler, NULL));
}
--
1.5.5.6
^ permalink raw reply related
* Re: [PATCH RESEND net-next V2] IB/ipoib: break linkage to neighbouring system
From: Or Gerlitz @ 2012-07-27 4:42 UTC (permalink / raw)
To: Roland Dreier; +Cc: David Miller, ogerlitz, netdev, eric.dumazet, cl, shlomop
In-Reply-To: <CAG4TOxNrywFPj_91RzkPikPoWP4hwe+2oninuF7zkrBFo6Q3Kg@mail.gmail.com>
On Wed, Jul 25, 2012 at 10:52 AM, Roland Dreier <roland@kernel.org> wrote:
> On Tue, Jul 24, 2012 at 2:00 PM, David Miller <davem@davemloft.net> wrote:
>> Looks good, Roland you got this?
> Yes, I'll read it over and pick it up, thanks.
Hi Roland,
Just to make sure, you are picking this for 3.6, correct?
I'd like to make sure that the merge of this patch through the
infiniband tree will not introduce dependancy with the review/merge of
the Ethernet IPoIB driver that runs through netdev. If this patch
lands in 3.6-rcX, Dave will eventually pick it into net-next and we're
ok, if not, things get complicated without any real reason, makes
sense?
Or.
^ permalink raw reply
* Re: [PATCH] iproute: Add route showdump command
From: Pavel Emelyanov @ 2012-07-27 4:14 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Dan Smith, Linux Netdev List
In-Reply-To: <20120726090315.4a566a46@nehalam.linuxnetplumber.net>
On 07/26/2012 08:03 PM, Stephen Hemminger wrote:
> 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.
> .
Hm... The idea with magic looks reasonable.
I will look at what can be done here, thanks!
^ permalink raw reply
* Re: [PATCH] r8169: revert "add byte queue limit support".
From: Stefan Lippers-Hollmann @ 2012-07-27 3:36 UTC (permalink / raw)
To: Francois Romieu
Cc: Eric Dumazet, David Miller, hayeswang, netdev,
Alex Villacís Lasso, Josh Boyer, Tom Herbert
In-Reply-To: <20120724053811.GA12053@electric-eye.fr.zoreil.com>
Hi
On Tuesday 24 July 2012, Francois Romieu wrote:
> Eric Dumazet <eric.dumazet@gmail.com> :
> > On Mon, 2012-07-23 at 22:55 +0200, Francois Romieu wrote:
> > > This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.
> [...]
> > bisection is not always the right way to qualify a problem.
>
> I know. At some point I switch from "I could search more" to "users situation
> will improve in a definite timeframe".
>
> > BQL in itself had some fixes coming _after_ commit 036dafa28da1e2565
>
> Thanks.
>
> They are in stable as of 3.4.5:
[…]
> I have obviously not directed users at them and I do not see any
> of the victims using a non -stable / -vendor or recent enough
> kernel to test this patch since the issue has been reported.
>
> They are both worth testing.
[…]
3.4.x up to and including 3.4.4 exposed the problem on these cards[1]:
r8169 0000:04:00.0: eth0: RTL8168d/8111d at 0xffffc90000c72000, 00:24:1d:72:7c:75, XID 081000c0 IRQ 44
r8169 0000:05:00.0: eth1: RTL8168d/8111d at 0xffffc90000c70000, 00:24:1d:72:7c:77, XID 081000c0 IRQ 45
while it is stable with "add byte queue limit support" reverted; 3.4.5+
was only tested with 036dafa28da1e2565a8529de2ae663c37b7a0060 reverted.
Now testing plain 3.5.0, which still includes it, has been reliable for
almost 3 days - while the issue usually triggered within one hour (3
hours at most) in 3.4.[0-4]. It might be a little too early to give a
definitive answer, but so far r8169/ 3.5.0 looks positive.
Regards
Stefan Lippers-Hollmann
[1] Message-Id: <201206290131.49150.s.L-H@gmx.de>
http://lkml.kernel.org/r/<201206290131.49150.s.L-H@gmx.de>
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-27 3:08 UTC (permalink / raw)
To: alexander.duyck; +Cc: eric.dumazet, netdev
In-Reply-To: <CAKgT0UdhqDQSFZkWw9w8L2qsCS+MM_DLQE+Vq0mKcYZmxhs=8Q@mail.gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Thu, 26 Jul 2012 19:14:55 -0700
> Any idea why these look-ups are so expensive in the first place? When
> I dump fib_trie it doesn't look like I have much there. I would have
> thought the table would be pretty static with just 8 flows all going
> to the same destination address, but it seems like I was getting hit
> with cache misses for some reason.
A lot of the overhead comes from write traffic that results from
filling in the "fib_result" structure onto the callers stack.
The return value from a fib_lookup() has far too many components. But
simplifying things is not easy.
^ permalink raw reply
* [PATCH] [XFRM] Fix unexpected SA hard expiration after changing date
From: Fan Du @ 2012-07-27 2:39 UTC (permalink / raw)
To: davem, herbert; +Cc: netdev
In-Reply-To: <1343356759-24767-1-git-send-email-fdu@windriver.com>
After SA is setup, one timer is armed to detect soft/hard expiration,
however the timer handler uses xtime to do the math. This makes hard
expiration occurs first before soft expiration after setting new date
with big interval. As a result new child SA is deleted before rekeying
the new one.
Signed-off-by: Fan Du <fdu@windriver.com>
---
include/net/xfrm.h | 4 ++++
net/xfrm/xfrm_state.c | 22 ++++++++++++++++++----
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index d9509eb..62b619e 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -213,6 +213,9 @@ struct xfrm_state {
struct xfrm_lifetime_cur curlft;
struct tasklet_hrtimer mtimer;
+ /* used to fix curlft->add_time when changing date */
+ long saved_tmo;
+
/* Last used time */
unsigned long lastused;
@@ -238,6 +241,7 @@ static inline struct net *xs_net(struct xfrm_state *x)
/* xflags - make enum if more show up */
#define XFRM_TIME_DEFER 1
+#define XFRM_SOFT_EXPIRE 2
enum {
XFRM_STATE_VOID,
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 5b228f9..fb64dc6 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -415,8 +415,18 @@ static enum hrtimer_restart xfrm_timer_handler(struct hrtimer * me)
if (x->lft.hard_add_expires_seconds) {
long tmo = x->lft.hard_add_expires_seconds +
x->curlft.add_time - now;
- if (tmo <= 0)
- goto expired;
+ if (tmo <= 0) {
+ if (x->xflags & XFRM_SOFT_EXPIRE) {
+ /* enter hard expire without soft expire first?!
+ * setting a new date could trigger this.
+ * workarbound: fix x->curflt.add_time by below:
+ */
+ x->curlft.add_time = now - x->saved_tmo - 1;
+ tmo = x->lft.hard_add_expires_seconds - x->saved_tmo;
+
+ } else
+ goto expired;
+ }
if (tmo < next)
next = tmo;
}
@@ -433,10 +443,14 @@ static enum hrtimer_restart xfrm_timer_handler(struct hrtimer * me)
if (x->lft.soft_add_expires_seconds) {
long tmo = x->lft.soft_add_expires_seconds +
x->curlft.add_time - now;
- if (tmo <= 0)
+ if (tmo <= 0) {
warn = 1;
- else if (tmo < next)
+ x->xflags &= ~XFRM_SOFT_EXPIRE;
+ } else if (tmo < next) {
next = tmo;
+ x->xflags |= XFRM_SOFT_EXPIRE;
+ x->saved_tmo = tmo;
+ }
}
if (x->lft.soft_use_expires_seconds) {
long tmo = x->lft.soft_use_expires_seconds +
--
1.7.1
^ permalink raw reply related
* [RESEND][XFRM][PATCH v4] Fix unexpected SA hard expiration after setting new date
From: Fan Du @ 2012-07-27 2:39 UTC (permalink / raw)
To: davem, herbert; +Cc: netdev
Hi, Dave
It has been more than one month since my last post of this patch.
Previous posting receives no objection from you and Herbert, so I
rebase it with latest linux-3.5, then it can be easily picked up.
I'm wondering could you please take a look at this patch ?
Any comments are really welcome!
Thanks
Changelog:
v1->v2
1) use xflags instead of creating new flags(suggested by Steffen Klassert)
v2->v3
1) fix email problem, and remove cc to myself(requested by David Miller)
v3->v4
1) fix typo when clearing XFRM_SOFT_EXPIRE(thanks for David Miller)
2) fix email problem, and remove cc to myself AGAIN!!!
*Background*:
Once IPsec SAs are created between two peers, kernel setup a timer to monitor
two events: soft/hard expiration. However the timer handler use xtime to
caculate whether it's soft or hard expiration event.
normal code flow(hard expire time:100s, soft expire time:82s)
a) When new SAs created, xfrm_timer_handler is called one second
after its creation. At this point, calculate soft expire
interval(81s), setup the timer;
b) soft expire occur, rearm the timer with hard expire interval(18s)
then notify racoon2 about soft expire event. racoon2 will create
new SAs.
c) hard expire happen, notify racoon2 about it. racoon2 will delete
the old SAs.
*Scenario*:
Setting a new date before b),and after a) could result c) happens first,
As a result, old SAs is deleted before new ones are created. Normally
new SAs will be created by the next time networking traffic, but there
is a small time being when networking connection is down, this could
result in upper layer connections failed in tel comm area, thus it's
better to keep it strict in sequence.
*Workaround*:
set new time could happen:
1) before a), then SAs is updated with new time.
2) before b),and after a)
2a) When new SAs created, xfrm_timer_handler is called one second
after its creation. At this point, calculate soft expire
interval(81s), setup the timer;(set flag to mark next time should
be soft time expire)
<<---- new date comes
2b) soft expire occur, the calculation results in a hard time expire
event, but flag is set, so catch ya. Sync the addtime, and rearm
the timer with hard expire interval(18s), then notify racoon2
about soft expire event;
2c) hard expire happen, notify racoon2 about it;
so everything is in order.
3) after b), hard expire always happened anyway.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Alexander Duyck @ 2012-07-27 2:14 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20120726.155327.947597248143903676.davem@davemloft.net>
On Thu, Jul 26, 2012 at 3:53 PM, David Miller <davem@davemloft.net> wrote:
> From: Alexander Duyck <alexander.duyck@gmail.com>
> Date: Thu, 26 Jul 2012 15:03:39 -0700
>
>> Here is the latest perf results with all of these patches in place.
>> As you predicted your patch essentially cut the lookup overhead in
>> half:
>
> Ok good.
>
> That patch is hard to make legitimate, I'd have to do a bit or work
> before we could realize that change.
>
> We can only combine the LOCAL and MAIN tables like that so long as
> there are no overlaps in the routes covered by the two tables. We'd
> also have to be sure to report the routes properly in dumps too.
>
> I really wish we had never segregated these two tables, it's
> completely pointless and hurts performance. But now we have to
> accomodate this legacy.
Any idea why these look-ups are so expensive in the first place? When
I dump fib_trie it doesn't look like I have much there. I would have
thought the table would be pretty static with just 8 flows all going
to the same destination address, but it seems like I was getting hit
with cache misses for some reason.
Thanks,
Alex
^ permalink raw reply
* Your webmail quota has exceeded
From: webmaster @ 2012-07-27 0:27 UTC (permalink / raw)
--
Your webmail quota has exceeded the set quota which is 2GB. you are
currently running on 2.3GB.To re-activate and increase your webmail
quota please verify and update your webmail Account
In order re-activate and increase your webmail quota click the link
below.
https://docs.google.com/spreadsheet/viewform?formkey=dGNMaWg1R1BKU2lWXzB0VlpEMnJYclE6MQ
Failure to do so may result in the cancellation of your webmail
account.
Thanks, and sorry for the inconvenience
Admin/ Webmaster/ Local host
^ permalink raw reply
* Your webmail quota has exceeded
From: webmaster @ 2012-07-27 0:26 UTC (permalink / raw)
--
Your webmail quota has exceeded the set quota which is 2GB. you are
currently running on 2.3GB.To re-activate and increase your webmail
quota please verify and update your webmail Account
In order re-activate and increase your webmail quota click the link
below.
https://docs.google.com/spreadsheet/viewform?formkey=dGNMaWg1R1BKU2lWXzB0VlpEMnJYclE6MQ
Failure to do so may result in the cancellation of your webmail
account.
Thanks, and sorry for the inconvenience
Admin/ Webmaster/ Local host
^ permalink raw reply
* Re: [PATCH iproute2] ss: report SK_MEMINFO_BACKLOG
From: Vijay Subramanian @ 2012-07-27 0:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1343294420.2626.11264.camel@edumazet-glaptop>
On 26 July 2012 02:20, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> linux-3.6-rc1 supports SK_MEMINFO_BACKLOG with commit d594e987c6f54
> (sock_diag: add SK_MEMINFO_BACKLOG)
>
> ss command can display it if provided by the kernel.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Vijay Subramanian <subramanian.vijay@gmail.com>
Thanks Eric. I see now how you fixed this.
Tested-by: Vijay Subramanian <subramanian.vijay@gmail.com>
Vijay
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-07-26 23:58 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Reinstate the no-ref optimization for input route lookups in ipv4
to fix some routing cache removal perf regressions.
2) Make TCP socket pre-demux work on ipv6 side too, from Eric Dumazet.
3) Get RX hash value from correct place in be2net driver, from
Sarveshwar Bandi.
4) Validation of FIB cached routes missing critical check, from Eric
Dumazet.
5) EEH support in mlx4 driver, from Kleber Sacilotto de Souza.
Please pull, thanks a lot!
The following changes since commit 3c4cfadef6a1665d9cd02a543782d03d3e6740c6:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2012-07-24 10:01:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to c7109986db3c945f50ceed884a30e0fd8af3b89b:
ipv6: Early TCP socket demux (2012-07-26 15:50:39 -0700)
----------------------------------------------------------------
Alan Cox (2):
caif: fix NULL pointer check
wanmain: comparing array with NULL
Amir Vadai (1):
net/mlx4_en: Limit the RFS filter IDs to be < RPS_NO_FILTER
Andy Cress (3):
pch_gbe: fix transmit watchdog timeout
pch_gbe: add extra clean tx
pch_gbe: vlan skb len fix
Anton Blanchard (1):
be2net: Missing byteswap in be_get_fw_log_level causes oops on PowerPC
Dan Williams (1):
cdc-ncm: tag Ericsson WWAN devices (eg F5521gw) with FLAG_WWAN
David S. Miller (1):
ipv4: Fix input route performance regression.
Emil Tantilov (1):
ixgbe: fix panic while dumping packets on Tx hang with IOMMU
Eric Dumazet (3):
tcp: early_demux fixes
ipv4: rt_cache_valid must check expired routes
ipv6: Early TCP socket demux
Haiyang Zhang (2):
hyperv: Add a check for ring_size value
hyperv: Add error handling to rndis_filter_device_add()
Jiri Pirko (1):
team: init error value to 0 in team_netpoll_setup()
Kleber Sacilotto de Souza (1):
mlx4: Add support for EEH error recovery
Sarveshwar Bandi (1):
be2net: Fix to parse RSS hash from Receive completions correctly.
Wei Yang (1):
net/pch_gpe: Cannot disable ethernet autonegation
Yuval Mintz (1):
bnx2x: Correct EEE statistics gathering
frank.blaschka@de.ibm.com (3):
net: wiznet add missing HAS_IOMEM dependency
netiucv: cleanup attribute usage
qeth: repair crash in qeth_l3_vlan_rx_kill_vid()
drivers/net/caif/caif_serial.c | 3 ++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h | 4 +++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 8 +++--
drivers/net/ethernet/emulex/benet/be_ethtool.c | 5 ++--
drivers/net/ethernet/emulex/benet/be_main.c | 6 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++----
drivers/net/ethernet/mellanox/mlx4/catas.c | 25 +++++++++++-----
drivers/net/ethernet/mellanox/mlx4/cmd.c | 49 +++++++++++++++++++++++++++++--
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 30 ++++++++++++++++++-
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c | 1 -
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 70 ++++++++++++++++++++++++++++++--------------
drivers/net/ethernet/wiznet/Kconfig | 1 +
drivers/net/hyperv/netvsc_drv.c | 7 ++++-
drivers/net/hyperv/rndis_filter.c | 11 +++----
drivers/net/team/team.c | 2 +-
drivers/net/usb/cdc_ncm.c | 68 +++++++++++++++++++++++++++---------------
drivers/s390/net/netiucv.c | 34 ++++-----------------
drivers/s390/net/qeth_l3_main.c | 4 +++
include/net/inet6_hashtables.h | 13 ++++----
include/net/protocol.h | 2 ++
include/net/route.h | 19 ++++++++++--
net/ipv4/arp.c | 2 +-
net/ipv4/fib_semantics.c | 4 +--
net/ipv4/ip_fragment.c | 4 +--
net/ipv4/ip_input.c | 10 +++++--
net/ipv4/route.c | 56 +++++++++++++++++------------------
net/ipv4/tcp_ipv4.c | 9 ++----
net/ipv4/xfrm4_input.c | 4 +--
net/ipv6/ip6_input.c | 13 ++++++--
net/ipv6/tcp_ipv6.c | 38 ++++++++++++++++++++++++
net/wanrouter/wanmain.c | 51 +++++++++++++++-----------------
32 files changed, 374 insertions(+), 192 deletions(-)
^ permalink raw reply
* Computations in tc_red.c
From: Dragos Ilie @ 2012-07-26 23:38 UTC (permalink / raw)
To: netdev
Hello,
I have a couple of questions about the function tc_red_eval_idle_damping() in iproute2/tc/tc_red.c. Originally, I sent the questions to Alexey Kuznetsov (for several months ago) since he is listed as the author, but did not receive a reply from him. Hence, I am directing my questions to the netdev mailing list.
My understanding is that the tc_red_eval_idle_damping() function pre-computes a set of values in the range 0-31. These values are later used by the kernel function red_calc_qavg_from_idle_time() in include/net/red.h to calculate the average queue size during idle time. The values represent the number of shifts applied to the current average queue size, which is a scaling factor of the form 2^(-n).
In tc_red_eval_idle_damping() the lW constant is defined as
double lW = -log(1.0 - 1.0/(1<<Wlog))/xmit_time
This is equivalent to -log(1.0 - W)/xmit_time, where W is scaled by a
negative power of two (Wlog is computed in tc_red_eval_ ewma()). The
constant is used to choose a time scaling factor called clog. The
condition used in choosing clog is
maxtime/1<<clog < 512
where maxtime = 31/lW. What is the reason for choosing 512 as upper bound?
My second question is about the average queue length computed in kernel function red_calc_qavg_from_idle_time() in include/net/red.h. According to the comment in that
function, the average queue length v->qavg should be adjusted as
v->qavg *= (1-W)^m
The code approximates this function by scaling v->qavg with 2^(-n),
where n was precomputed in c_red_eval_idle_damping(). I have trouble
seeing the connection between the log() function used to compute the
constant lW and the approximation used. I am hoping you can shed some
light on it.
Best regards,
Dragos Ilie
^ permalink raw reply
* anyone know of a bug which causes dev->qdisc to be noop_qdisc for a working interface?
From: Chris Friesen @ 2012-07-26 23:30 UTC (permalink / raw)
To: netdev
Hi all,
I've been asked to help debug an issue we've had in the field where
after a month or so of uptime for a server the router it was connected
to was rebooted and one of the eth links stopped transmitting packets.
Downing and upping the link doesn't fix it. An ethtool offline selftest
doesn't fix it. Only known fix is a reboot of the server.
The server is running 2.6.14, which makes things interesting.
Luckily we had kprobes enabled and I tracked down the source code, and
I've been able to isolate the source of the problem. It seems that for
the problematic eth device (which is up and is receiving packets)
dev->qdisc is set to noop_qdisc, which ends up silently dropping all
outgoing packets on the floor. dev->qdisc_sleeping is pfifo_fast as
expected.
Does anyone have any ideas how this might have happened? Does anyone
remember a bug in this area from that long ago?
Thanks,
Chris
--
Chris Friesen
Software Designer
3500 Carling Avenue
Ottawa, Ontario K2H 8E9
www.genband.com
^ permalink raw reply
* Re: [PATCH v2] ipv6: Early TCP socket demux
From: David Miller @ 2012-07-26 22:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1343341091.2626.12092.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 27 Jul 2012 00:18:11 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> This is the IPv6 missing bits for infrastructure added in commit
> 41063e9dd1195 (ipv4: Early TCP socket demux.)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] ipv4: Fix input route performance regression.
From: David Miller @ 2012-07-26 22:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: alexander.duyck, netdev
In-Reply-To: <1343340989.2626.12087.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 27 Jul 2012 00:16:29 +0200
> On Thu, 2012-07-26 at 14:14 -0700, David Miller wrote:
>> With the routing cache removal we lost the "noref" code paths on
>> input, and this can kill some routing workloads.
>>
>> Reinstate the noref path when we hit a cached route in the FIB
>> nexthops.
>>
>> With help from Eric Dumazet.
>>
>> Reported-by: Alexander Duyck <alexander.duyck@gmail.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Thanks for reviewing.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-26 22:53 UTC (permalink / raw)
To: alexander.duyck; +Cc: eric.dumazet, netdev
In-Reply-To: <CAKgT0Ue4mRUpEmKA7SNpTv8D7BKcxYQ65PGoOUkxB27sLuT1Rw@mail.gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Thu, 26 Jul 2012 15:03:39 -0700
> Here is the latest perf results with all of these patches in place.
> As you predicted your patch essentially cut the lookup overhead in
> half:
Ok good.
That patch is hard to make legitimate, I'd have to do a bit or work
before we could realize that change.
We can only combine the LOCAL and MAIN tables like that so long as
there are no overlaps in the routes covered by the two tables. We'd
also have to be sure to report the routes properly in dumps too.
I really wish we had never segregated these two tables, it's
completely pointless and hurts performance. But now we have to
accomodate this legacy.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-26 22:48 UTC (permalink / raw)
To: shemminger; +Cc: alexander.duyck, eric.dumazet, netdev
In-Reply-To: <20120726151312.2f3d9e02@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 26 Jul 2012 15:13:12 -0700
> The fib trie stats are global, you may want to either disable
> CONFIG_IP_FIB_TRIE_STATS or convert them to per-cpu.
Oh yeah, turn that stuff off when testing :-)
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-26 22:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Alexander Duyck, David Miller, netdev
In-Reply-To: <20120726151312.2f3d9e02@nehalam.linuxnetplumber.net>
On Thu, 2012-07-26 at 15:13 -0700, Stephen Hemminger wrote:
> The fib trie stats are global, you may want to either disable CONFIG_IP_FIB_TRIE_STATS
> or convert them to per-cpu.
I guess its already disabled in Alex case ;)
^ permalink raw reply
* [PATCH v2] ipv6: Early TCP socket demux
From: Eric Dumazet @ 2012-07-26 22:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
This is the IPv6 missing bits for infrastructure added in commit
41063e9dd1195 (ipv4: Early TCP socket demux.)
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
v2: export sysctl_ip_early_demux
remove unlikely() in __inet6_lookup_skb()
include/net/inet6_hashtables.h | 13 +++++-----
include/net/protocol.h | 2 +
net/ipv4/ip_input.c | 1
net/ipv6/ip6_input.c | 13 ++++++++--
net/ipv6/tcp_ipv6.c | 38 +++++++++++++++++++++++++++++++
5 files changed, 59 insertions(+), 8 deletions(-)
diff --git a/include/net/inet6_hashtables.h b/include/net/inet6_hashtables.h
index 00cbb43..9e34c87 100644
--- a/include/net/inet6_hashtables.h
+++ b/include/net/inet6_hashtables.h
@@ -96,14 +96,15 @@ static inline struct sock *__inet6_lookup_skb(struct inet_hashinfo *hashinfo,
const __be16 sport,
const __be16 dport)
{
- struct sock *sk;
+ struct sock *sk = skb_steal_sock(skb);
- if (unlikely(sk = skb_steal_sock(skb)))
+ if (sk)
return sk;
- else return __inet6_lookup(dev_net(skb_dst(skb)->dev), hashinfo,
- &ipv6_hdr(skb)->saddr, sport,
- &ipv6_hdr(skb)->daddr, ntohs(dport),
- inet6_iif(skb));
+
+ return __inet6_lookup(dev_net(skb_dst(skb)->dev), hashinfo,
+ &ipv6_hdr(skb)->saddr, sport,
+ &ipv6_hdr(skb)->daddr, ntohs(dport),
+ inet6_iif(skb));
}
extern struct sock *inet6_lookup(struct net *net, struct inet_hashinfo *hashinfo,
diff --git a/include/net/protocol.h b/include/net/protocol.h
index 057f2d3..929528c 100644
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -52,6 +52,8 @@ struct net_protocol {
#if IS_ENABLED(CONFIG_IPV6)
struct inet6_protocol {
+ void (*early_demux)(struct sk_buff *skb);
+
int (*handler)(struct sk_buff *skb);
void (*err_handler)(struct sk_buff *skb,
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 93134b0..4126c96 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -314,6 +314,7 @@ drop:
}
int sysctl_ip_early_demux __read_mostly = 1;
+EXPORT_SYMBOL(sysctl_ip_early_demux);
static int ip_rcv_finish(struct sk_buff *skb)
{
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 5ab923e..47975e3 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -47,9 +47,18 @@
-inline int ip6_rcv_finish( struct sk_buff *skb)
+int ip6_rcv_finish(struct sk_buff *skb)
{
- if (skb_dst(skb) == NULL)
+ if (sysctl_ip_early_demux && !skb_dst(skb)) {
+ const struct inet6_protocol *ipprot;
+
+ rcu_read_lock();
+ ipprot = rcu_dereference(inet6_protos[ipv6_hdr(skb)->nexthdr]);
+ if (ipprot && ipprot->early_demux)
+ ipprot->early_demux(skb);
+ rcu_read_unlock();
+ }
+ if (!skb_dst(skb))
ip6_route_input(skb);
return dst_input(skb);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index f49476e..221224e 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1674,6 +1674,43 @@ do_time_wait:
goto discard_it;
}
+static void tcp_v6_early_demux(struct sk_buff *skb)
+{
+ const struct ipv6hdr *hdr;
+ const struct tcphdr *th;
+ struct sock *sk;
+
+ if (skb->pkt_type != PACKET_HOST)
+ return;
+
+ if (!pskb_may_pull(skb, skb_transport_offset(skb) + sizeof(struct tcphdr)))
+ return;
+
+ hdr = ipv6_hdr(skb);
+ th = tcp_hdr(skb);
+
+ if (th->doff < sizeof(struct tcphdr) / 4)
+ return;
+
+ sk = __inet6_lookup_established(dev_net(skb->dev), &tcp_hashinfo,
+ &hdr->saddr, th->source,
+ &hdr->daddr, ntohs(th->dest),
+ inet6_iif(skb));
+ if (sk) {
+ skb->sk = sk;
+ skb->destructor = sock_edemux;
+ if (sk->sk_state != TCP_TIME_WAIT) {
+ struct dst_entry *dst = sk->sk_rx_dst;
+ struct inet_sock *icsk = inet_sk(sk);
+ if (dst)
+ dst = dst_check(dst, 0);
+ if (dst &&
+ icsk->rx_dst_ifindex == inet6_iif(skb))
+ skb_dst_set_noref(skb, dst);
+ }
+ }
+}
+
static struct timewait_sock_ops tcp6_timewait_sock_ops = {
.twsk_obj_size = sizeof(struct tcp6_timewait_sock),
.twsk_unique = tcp_twsk_unique,
@@ -1984,6 +2021,7 @@ struct proto tcpv6_prot = {
};
static const struct inet6_protocol tcpv6_protocol = {
+ .early_demux = tcp_v6_early_demux,
.handler = tcp_v6_rcv,
.err_handler = tcp_v6_err,
.gso_send_check = tcp_v6_gso_send_check,
^ permalink raw reply related
* Re: [PATCH] ipv4: Fix input route performance regression.
From: Eric Dumazet @ 2012-07-26 22:16 UTC (permalink / raw)
To: David Miller; +Cc: alexander.duyck, netdev
In-Reply-To: <20120726.141438.1996323620706359167.davem@davemloft.net>
On Thu, 2012-07-26 at 14:14 -0700, David Miller wrote:
> With the routing cache removal we lost the "noref" code paths on
> input, and this can kill some routing workloads.
>
> Reinstate the noref path when we hit a cached route in the FIB
> nexthops.
>
> With help from Eric Dumazet.
>
> Reported-by: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Stephen Hemminger @ 2012-07-26 22:13 UTC (permalink / raw)
To: Alexander Duyck; +Cc: David Miller, eric.dumazet, netdev
In-Reply-To: <CAKgT0Ue4mRUpEmKA7SNpTv8D7BKcxYQ65PGoOUkxB27sLuT1Rw@mail.gmail.com>
On Thu, 26 Jul 2012 15:03:39 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> On Thu, Jul 26, 2012 at 2:06 PM, David Miller <davem@davemloft.net> wrote:
> > From: Alexander Duyck <alexander.duyck@gmail.com>
> > Date: Thu, 26 Jul 2012 11:26:26 -0700
> >
> >> 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.
> >
> > For fun you might want to see what this patch does for your tests,
> > it should cut the number of fib_table_lookup() calls roughly in half.
>
> So with your patch, Eric's patch, and this most recent patch we are
> now at 11.8Mpps with 8 or 9 queues. At this point I am staring to hit
> the hardware limits since 82599 will typically max out at about 12Mpps
> w/ 9 queues.
>
> Here is the latest perf results with all of these patches in place.
> As you predicted your patch essentially cut the lookup overhead in
> half:
> 10.65% [k] ixgbe_poll
> 7.77% [k] fib_table_lookup
> 6.21% [k] ixgbe_xmit_frame_ring
> 6.08% [k] __netif_receive_skb
> 4.41% [k] _raw_spin_lock
> 3.95% [k] kmem_cache_free
> 3.30% [k] build_skb
> 3.17% [k] memcpy
> 2.96% [k] dev_queue_xmit
> 2.79% [k] ip_finish_output
> 2.66% [k] kmem_cache_alloc
> 2.57% [k] check_leaf
> 2.52% [k] ip_route_input_noref
> 2.50% [k] netdev_alloc_frag
> 2.17% [k] ip_rcv
> 2.16% [k] __phys_addr
>
> I will probably do some more poking around over the next few days in
> order to get my head around the fib_table_lookup overhead.
>
> Thanks,
>
> Alex
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
The fib trie stats are global, you may want to either disable CONFIG_IP_FIB_TRIE_STATS
or convert them to per-cpu.
^ permalink raw reply
* Re: [PATCH] ipv6: Early TCP socket demux
From: Eric Dumazet @ 2012-07-26 22:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120726.142903.2061753292000961457.davem@davemloft.net>
On Thu, 2012-07-26 at 14:29 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 26 Jul 2012 12:34:28 +0200
>
> > + if (sysctl_ip_early_demux && !skb_dst(skb)) {
>
> You obviously don't build ipv6 modular.
>
> sysctl_ip_early_demux needs to be exported to modules in order
> for this to work.
Humpf....
I'll also remove the unlikely() in __inet6_lookup_skb() in v2
Thanks
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Alexander Duyck @ 2012-07-26 22:03 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20120726.140601.1137230112117936793.davem@davemloft.net>
On Thu, Jul 26, 2012 at 2:06 PM, David Miller <davem@davemloft.net> wrote:
> From: Alexander Duyck <alexander.duyck@gmail.com>
> Date: Thu, 26 Jul 2012 11:26:26 -0700
>
>> 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.
>
> For fun you might want to see what this patch does for your tests,
> it should cut the number of fib_table_lookup() calls roughly in half.
So with your patch, Eric's patch, and this most recent patch we are
now at 11.8Mpps with 8 or 9 queues. At this point I am staring to hit
the hardware limits since 82599 will typically max out at about 12Mpps
w/ 9 queues.
Here is the latest perf results with all of these patches in place.
As you predicted your patch essentially cut the lookup overhead in
half:
10.65% [k] ixgbe_poll
7.77% [k] fib_table_lookup
6.21% [k] ixgbe_xmit_frame_ring
6.08% [k] __netif_receive_skb
4.41% [k] _raw_spin_lock
3.95% [k] kmem_cache_free
3.30% [k] build_skb
3.17% [k] memcpy
2.96% [k] dev_queue_xmit
2.79% [k] ip_finish_output
2.66% [k] kmem_cache_alloc
2.57% [k] check_leaf
2.52% [k] ip_route_input_noref
2.50% [k] netdev_alloc_frag
2.17% [k] ip_rcv
2.16% [k] __phys_addr
I will probably do some more poking around over the next few days in
order to get my head around the fib_table_lookup overhead.
Thanks,
Alex
^ 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