* 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
* 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
* 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
* 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
* [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
* [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
* 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
* 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] 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 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
* [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
* [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
* Re: [PATCH 2/2] iproute: Add route showdump command (v2)
From: Pavel Emelyanov @ 2012-07-27 5:03 UTC (permalink / raw)
To: Stephen Hemminger, Linux Netdev List
In-Reply-To: <50121FB0.6060200@parallels.com>
Stephen, I have a question regarding the save and restore in iproute tool.
As you know, the save/restore pair for routes works in a very simple and
elegant manner -- on save the raw kernel rtnl stream is just put into a
file, on restore the _very_ _same_ messages are pushed back to the kernel.
Is the same trick possible to save and restore the addresses (the ip
addr command) as well? Or the RTM_GETADDR messages cannot be just read
from and written back to the network stack in a generic case?
Thanks,
Pavel
^ permalink raw reply
* Re: [PATCH] r8169: revert "add byte queue limit support".
From: Eric Dumazet @ 2012-07-27 5:27 UTC (permalink / raw)
To: Stefan Lippers-Hollmann
Cc: Francois Romieu, David Miller, hayeswang, netdev,
Alex Villacís Lasso, Josh Boyer, Tom Herbert
In-Reply-To: <201207270536.50292.s.L-H@gmx.de>
On Fri, 2012-07-27 at 05:36 +0200, Stefan Lippers-Hollmann wrote:
> 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>
Thats real good news, thanks !
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-27 6:02 UTC (permalink / raw)
To: alexander.duyck; +Cc: eric.dumazet, netdev
In-Reply-To: <20120726.200846.66786272076299783.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 26 Jul 2012 20:08:46 -0700 (PDT)
> A lot of the overhead comes from write traffic that results from
> filling in the "fib_result" structure onto the callers stack.
Here's the longer analysis of how things are now.
There are several components to a route lookup result, and struct
fib_result tries to encapsulate all of this.
Another aspect is that our route tables are broken up into different
datas tructures which reference each other, in order to save space.
So the actual objects in the FIB trie are fib_alias structures, and
those point to fib_info. There is a many to one relationship between
FIB trie nodes and fib_info objects.
The idea is that many routes have the same set of nexthops, metrics,
preferred source address, etc.
So one thing we return in the fib_result is a pointer to the fib_info
and an index into the nexthop array (nh_sel). That's why we have all
of these funny accessor's FIB_RES_X(res) which essentially provide
res.fi->fib_nh[res.nh_sel].X
Therefore one area of simplification would be to just return a pointer
to the FIB nexthop, rather than the fib_info pointer and the nexthop
index. We can get to the fib_info, if we need to, via the nh_parent
pointer of the nexthop.
It seems also that the res->scope value can be cribbed from the
fib_info as well.
res->type is embedded in the fib_alias we select hanging off of the
FIB trie node. And the res->prefixlen is taken from the FIB trie
node.
res->tclassid is problematic, because it comes from the FIB rules
tables rather than the FIB trie. We used to store a full FIB rules
pointer in the fib_result, but I reduced it down to just the u32
tclassid.
This whole area, as well as the FIB trie lookup itself, is an area
ripe for a large number of small micro-optimizations that in the end
make it's overhead much more reasonable.
Another thing I haven't mentioned is that another part of FIB trie's
overhead is that it does backtracking. The shorter prefixes sit at
the top of the trie, so when it traverses down it does so until it
can't get a match, then it walks back up to the root until it does
have a match.
^ permalink raw reply
* Re: [PATCH 2/2] iproute: Add route showdump command (v2)
From: Pavel Emelyanov @ 2012-07-27 6:06 UTC (permalink / raw)
To: Stephen Hemminger, Linux Netdev List
In-Reply-To: <5012211A.4040307@parallels.com>
On 07/27/2012 09:03 AM, Pavel Emelyanov wrote:
> As you know, the save/restore pair for routes works in a very simple and
> elegant manner -- on save the raw kernel rtnl stream is just put into a
> file, on restore the _very_ _same_ messages are pushed back to the kernel.
>
> Is the same trick possible to save and restore the addresses (the ip
> addr command) as well? Or the RTM_GETADDR messages cannot be just read
> from and written back to the network stack in a generic case?
I mean something like the below, just put the RTM_GETADDR stream into a
file and push it back into the kernel as is. It worked for me in trivial
cases, but is this approach correct generically?
Log:
iproute: Add ability to save, restore and show the interfaces' addresses
Implementation is similar to the ip route {save|restore|showdump} one.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 37deda5..6788544 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -34,6 +34,11 @@
#include "ll_map.h"
#include "ip_common.h"
+enum {
+ IPADD_LIST,
+ IPADD_FLUSH,
+ IPADD_SAVE,
+};
static struct
{
@@ -65,8 +70,9 @@ static void usage(void)
fprintf(stderr, "Usage: ip addr {add|change|replace} IFADDR dev STRING [ LIFETIME ]\n");
fprintf(stderr, " [ CONFFLAG-LIST ]\n");
fprintf(stderr, " ip addr del IFADDR dev STRING\n");
- fprintf(stderr, " ip addr {show|flush} [ dev STRING ] [ scope SCOPE-ID ]\n");
+ fprintf(stderr, " ip addr {show|save|flush} [ dev STRING ] [ scope SCOPE-ID ]\n");
fprintf(stderr, " [ to PREFIX ] [ FLAG-LIST ] [ label PATTERN ]\n");
+ fprintf(stderr, " ip addr {showdump|restore}\n");
fprintf(stderr, "IFADDR := PREFIX | ADDR peer PREFIX\n");
fprintf(stderr, " [ broadcast ADDR ] [ anycast ADDR ]\n");
fprintf(stderr, " [ label STRING ] [ scope SCOPE-ID ]\n");
@@ -768,6 +774,99 @@ static int store_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n,
return 0;
}
+static __u32 ipadd_dump_magic = 0x47361222;
+
+static int ipadd_save_prep(void)
+{
+ int ret;
+
+ if (isatty(STDOUT_FILENO)) {
+ fprintf(stderr, "Not sending binary stream to stdout\n");
+ return -1;
+ }
+
+ ret = write(STDOUT_FILENO, &ipadd_dump_magic, sizeof(ipadd_dump_magic));
+ if (ret != sizeof(ipadd_dump_magic)) {
+ fprintf(stderr, "Can't write magic to dump file\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static int ipadd_dump_check_magic(void)
+{
+ int ret;
+ __u32 magic = 0;
+
+ if (isatty(STDIN_FILENO)) {
+ fprintf(stderr, "Can't restore addr dump from a terminal\n");
+ return -1;
+ }
+
+ ret = fread(&magic, sizeof(magic), 1, stdin);
+ if (magic != ipadd_dump_magic) {
+ fprintf(stderr, "Magic mismatch (%d elems, %x magic)\n", ret, magic);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int save_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n,
+ void *arg)
+{
+ int ret;
+
+ ret = write(STDOUT_FILENO, n, n->nlmsg_len);
+ if ((ret > 0) && (ret != n->nlmsg_len)) {
+ fprintf(stderr, "Short write while saving nlmsg\n");
+ ret = -EIO;
+ }
+
+ return ret == n->nlmsg_len ? 0 : ret;
+}
+
+static int show_handler(const struct sockaddr_nl *nl, struct nlmsghdr *n, void *arg)
+{
+ struct ifaddrmsg *ifa = NLMSG_DATA(n);
+
+ printf("if%d:\n", ifa->ifa_index);
+ print_addrinfo(NULL, n, stdout);
+ return 0;
+}
+
+static int ipaddr_showdump(void)
+{
+ if (ipadd_dump_check_magic())
+ exit(-1);
+
+ exit(rtnl_from_file(stdin, &show_handler, NULL));
+}
+
+static int restore_handler(const struct sockaddr_nl *nl, struct nlmsghdr *n, void *arg)
+{
+ int ret;
+
+ n->nlmsg_flags |= NLM_F_REQUEST | NLM_F_CREATE | NLM_F_ACK;
+
+ ll_init_map(&rth);
+
+ ret = rtnl_talk(&rth, n, 0, 0, n);
+ if ((ret < 0) && (errno == EEXIST))
+ ret = 0;
+
+ return ret;
+}
+
+static int ipaddr_restore(void)
+{
+ if (ipadd_dump_check_magic())
+ exit(-1);
+
+ exit(rtnl_from_file(stdin, &restore_handler, NULL));
+}
+
static void free_nlmsg_chain(struct nlmsg_chain *info)
{
struct nlmsg_list *l, *n;
@@ -902,7 +1001,7 @@ static int ipaddr_flush(void)
return 1;
}
-static int ipaddr_list_or_flush(int argc, char **argv, int flush)
+static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
{
struct nlmsg_chain linfo = { NULL, NULL};
struct nlmsg_chain ainfo = { NULL, NULL};
@@ -918,7 +1017,7 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
filter.group = INIT_NETDEV_GROUP;
- if (flush) {
+ if (action == IPADD_FLUSH) {
if (argc <= 0) {
fprintf(stderr, "Flush requires arguments.\n");
@@ -1005,9 +1104,26 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
}
}
- if (flush)
+ if (action == IPADD_FLUSH)
return ipaddr_flush();
+ if (action == IPADD_SAVE) {
+ if (ipadd_save_prep())
+ exit(1);
+
+ if (rtnl_wilddump_request(&rth, preferred_family, RTM_GETADDR) < 0) {
+ perror("Cannot send dump request");
+ exit(1);
+ }
+
+ if (rtnl_dump_filter(&rth, save_nlmsg, stdout) < 0) {
+ fprintf(stderr, "Save terminated\n");
+ exit(1);
+ }
+
+ exit(0);
+ }
+
if (rtnl_wilddump_request(&rth, preferred_family, RTM_GETLINK) < 0) {
perror("Cannot send dump request");
exit(1);
@@ -1055,7 +1171,7 @@ int ipaddr_list_link(int argc, char **argv)
{
preferred_family = AF_PACKET;
do_link = 1;
- return ipaddr_list_or_flush(argc, argv, 0);
+ return ipaddr_list_flush_or_save(argc, argv, IPADD_LIST);
}
void ipaddr_reset_filter(int oneline)
@@ -1271,7 +1387,7 @@ static int ipaddr_modify(int cmd, int flags, int argc, char **argv)
int do_ipaddr(int argc, char **argv)
{
if (argc < 1)
- return ipaddr_list_or_flush(0, NULL, 0);
+ return ipaddr_list_flush_or_save(0, NULL, IPADD_LIST);
if (matches(*argv, "add") == 0)
return ipaddr_modify(RTM_NEWADDR, NLM_F_CREATE|NLM_F_EXCL, argc-1, argv+1);
if (matches(*argv, "change") == 0 ||
@@ -1283,9 +1399,15 @@ int do_ipaddr(int argc, char **argv)
return ipaddr_modify(RTM_DELADDR, 0, argc-1, argv+1);
if (matches(*argv, "list") == 0 || matches(*argv, "show") == 0
|| matches(*argv, "lst") == 0)
- return ipaddr_list_or_flush(argc-1, argv+1, 0);
+ return ipaddr_list_flush_or_save(argc-1, argv+1, IPADD_LIST);
if (matches(*argv, "flush") == 0)
- return ipaddr_list_or_flush(argc-1, argv+1, 1);
+ return ipaddr_list_flush_or_save(argc-1, argv+1, IPADD_FLUSH);
+ if (matches(*argv, "save") == 0)
+ return ipaddr_list_flush_or_save(argc-1, argv+1, IPADD_SAVE);
+ if (matches(*argv, "showdump") == 0)
+ return ipaddr_showdump();
+ if (matches(*argv, "restore") == 0)
+ return ipaddr_restore();
if (matches(*argv, "help") == 0)
usage();
fprintf(stderr, "Command \"%s\" is unknown, try \"ip addr help\".\n", *argv);
^ permalink raw reply related
* [PATCH] tcp: Add TCP_USER_TIMEOUT negative value check
From: Hangbin Liu @ 2012-07-27 8:52 UTC (permalink / raw)
To: netdev; +Cc: hkchu, Hangbin Liu
TCP_USER_TIMEOUT is a TCP level socket option that takes an unsigned int. But
patch "tcp: Add TCP_USER_TIMEOUT socket option"(dca43c75) didn't check the negative
values. If a user assign -1 to it, the socket will set successfully and wait
for 4294967295 miliseconds. This patch add a negative value check to avoid
this issue.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv4/tcp.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 581ecf0..e7e6eea 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2681,7 +2681,10 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
/* Cap the max timeout in ms TCP will retry/retrans
* before giving up and aborting (ETIMEDOUT) a connection.
*/
- icsk->icsk_user_timeout = msecs_to_jiffies(val);
+ if (val < 0)
+ err = -EINVAL;
+ else
+ icsk->icsk_user_timeout = msecs_to_jiffies(val);
break;
default:
err = -ENOPROTOOPT;
--
1.7.7.6
^ permalink raw reply related
* Re: r8169, 3.5.0, does't work at all
From: Francois Romieu @ 2012-07-27 9:13 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <e9e38770b95bc3664fdc642fdfb65a13@visp.net.lb>
Denys Fedoryshchenko <denys@visp.net.lb> :
[...]
> and i can search for more machines with similar cards.
Thanks.
There seems to be a more recent bios for this motherboard. Is the second
8168b an add-on or is it a dual-port DH61HO ?
You are using x86 32 with PAE and slub where I use x86 64 with slab.
I am building a x86 32 bits test configuration for a 8168b right now.
Let's see what happened during the 3.4 .. 3.5 cycle in the r8169 driver:
- You may revert 7dbb491878a2c51d372a8890fa45a8ff80358af1 ("r8169: avoid NAPI
scheduling delay.")
I can see a napi rtl8169_poll failing to schedule rtl_slow_event_work
when it is already scheduled on a different cpu, said rtl_slow_event_work
running while rtl8169_poll is delayed and rtl8169_poll stomping on the
IntrMask after rtl_slow_event_work did.
It does not tell why the device does not recover after the netdev watchdog
but it could be worth trying.
- You may revert 851e60221926a53344b4227879858bef841b0477 ("r8169: Config1 is
read-only on 8168c and later.") as well.
It changes the PMEEnable write ordering for the 8168b (RTL_GIGA_MAC_VER_17)
and a few others chipset.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-27 10:01 UTC (permalink / raw)
To: David Miller; +Cc: alexander.duyck, netdev
In-Reply-To: <20120726.230246.219188476590178857.davem@davemloft.net>
From: Eric Dumazet <edumazet@google.com>
On Thu, 2012-07-26 at 23:02 -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 26 Jul 2012 20:08:46 -0700 (PDT)
>
> > A lot of the overhead comes from write traffic that results from
> > filling in the "fib_result" structure onto the callers stack.
>
> Here's the longer analysis of how things are now.
>
> There are several components to a route lookup result, and struct
> fib_result tries to encapsulate all of this.
>
> Another aspect is that our route tables are broken up into different
> datas tructures which reference each other, in order to save space.
>
> So the actual objects in the FIB trie are fib_alias structures, and
> those point to fib_info. There is a many to one relationship between
> FIB trie nodes and fib_info objects.
>
> The idea is that many routes have the same set of nexthops, metrics,
> preferred source address, etc.
>
> So one thing we return in the fib_result is a pointer to the fib_info
> and an index into the nexthop array (nh_sel). That's why we have all
> of these funny accessor's FIB_RES_X(res) which essentially provide
> res.fi->fib_nh[res.nh_sel].X
>
> Therefore one area of simplification would be to just return a pointer
> to the FIB nexthop, rather than the fib_info pointer and the nexthop
> index. We can get to the fib_info, if we need to, via the nh_parent
> pointer of the nexthop.
>
> It seems also that the res->scope value can be cribbed from the
> fib_info as well.
>
> res->type is embedded in the fib_alias we select hanging off of the
> FIB trie node. And the res->prefixlen is taken from the FIB trie
> node.
>
> res->tclassid is problematic, because it comes from the FIB rules
> tables rather than the FIB trie. We used to store a full FIB rules
> pointer in the fib_result, but I reduced it down to just the u32
> tclassid.
>
> This whole area, as well as the FIB trie lookup itself, is an area
> ripe for a large number of small micro-optimizations that in the end
> make it's overhead much more reasonable.
>
> Another thing I haven't mentioned is that another part of FIB trie's
> overhead is that it does backtracking. The shorter prefixes sit at
> the top of the trie, so when it traverses down it does so until it
> can't get a match, then it walks back up to the root until it does
> have a match.
We also have cache line misses in this code, and we shouldn't have them
at all.
Following patch helps a lot in my case.
Thanks
[PATCH] ipv4: fib: avoid false sharing
Now IP route cache is removed, we should make sure fib structures
cant share cache lines with possibly often dirtied objects.
On x86, kmalloc-96 cache can be source of such problems.
Problem spotted with perf ... -e cache-misses ... while doing
a forwarding benchmark.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/ip_fib.h | 6 ++++++
net/ipv4/fib_frontend.c | 5 +----
net/ipv4/fib_semantics.c | 15 ++++++++-------
net/ipv4/fib_trie.c | 26 +++++++++-----------------
4 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index e69c3a4..5b6a9b3 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -295,6 +295,12 @@ extern void fib_select_multipath(struct fib_result *res);
/* Exported by fib_trie.c */
extern void fib_trie_init(void);
extern struct fib_table *fib_trie_table(u32 id);
+static inline void *fib_zalloc(size_t size)
+{
+ /* We want to avoid possible false sharing */
+ return kzalloc(max_t(size_t, 128, size), GFP_KERNEL);
+}
+
static inline void fib_combine_itag(u32 *itag, const struct fib_result *res)
{
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 8732cc7..a3d0285 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -1089,10 +1089,7 @@ static int __net_init ip_fib_net_init(struct net *net)
int err;
size_t size = sizeof(struct hlist_head) * FIB_TABLE_HASHSZ;
- /* Avoid false sharing : Use at least a full cache line */
- size = max_t(size_t, size, L1_CACHE_BYTES);
-
- net->ipv4.fib_table_hash = kzalloc(size, GFP_KERNEL);
+ net->ipv4.fib_table_hash = fib_zalloc(size);
if (net->ipv4.fib_table_hash == NULL)
return -ENOMEM;
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index da0cc2e..a9f5e87 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -651,17 +651,17 @@ static inline unsigned int fib_laddr_hashfn(__be32 val)
((__force u32)val >> 14)) & mask;
}
-static struct hlist_head *fib_info_hash_alloc(int bytes)
+static struct hlist_head *fib_info_hash_alloc(size_t bytes)
{
if (bytes <= PAGE_SIZE)
- return kzalloc(bytes, GFP_KERNEL);
+ return fib_zalloc(bytes);
else
return (struct hlist_head *)
__get_free_pages(GFP_KERNEL | __GFP_ZERO,
get_order(bytes));
}
-static void fib_info_hash_free(struct hlist_head *hash, int bytes)
+static void fib_info_hash_free(struct hlist_head *hash, size_t bytes)
{
if (!hash)
return;
@@ -678,7 +678,8 @@ static void fib_info_hash_move(struct hlist_head *new_info_hash,
{
struct hlist_head *old_info_hash, *old_laddrhash;
unsigned int old_size = fib_info_hash_size;
- unsigned int i, bytes;
+ unsigned int i;
+ size_t bytes;
spin_lock_bh(&fib_info_lock);
old_info_hash = fib_info_hash;
@@ -766,10 +767,10 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
unsigned int new_size = fib_info_hash_size << 1;
struct hlist_head *new_info_hash;
struct hlist_head *new_laddrhash;
- unsigned int bytes;
+ size_t bytes;
if (!new_size)
- new_size = 1;
+ new_size = 16;
bytes = new_size * sizeof(struct hlist_head *);
new_info_hash = fib_info_hash_alloc(bytes);
new_laddrhash = fib_info_hash_alloc(bytes);
@@ -783,7 +784,7 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
goto failure;
}
- fi = kzalloc(sizeof(*fi)+nhs*sizeof(struct fib_nh), GFP_KERNEL);
+ fi = fib_zalloc(sizeof(*fi) + nhs*sizeof(struct fib_nh));
if (fi == NULL)
goto failure;
if (cfg->fc_mx) {
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 18cbc15..664152c 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -379,7 +379,7 @@ static inline void free_leaf_info(struct leaf_info *leaf)
static struct tnode *tnode_alloc(size_t size)
{
if (size <= PAGE_SIZE)
- return kzalloc(size, GFP_KERNEL);
+ return fib_zalloc(size);
else
return vzalloc(size);
}
@@ -449,7 +449,7 @@ static struct leaf *leaf_new(void)
static struct leaf_info *leaf_info_new(int plen)
{
- struct leaf_info *li = kmalloc(sizeof(struct leaf_info), GFP_KERNEL);
+ struct leaf_info *li = fib_zalloc(sizeof(struct leaf_info));
if (li) {
li->plen = plen;
li->mask_plen = ntohl(inet_make_mask(plen));
@@ -1969,32 +1969,24 @@ void __init fib_trie_init(void)
{
fn_alias_kmem = kmem_cache_create("ip_fib_alias",
sizeof(struct fib_alias),
- 0, SLAB_PANIC, NULL);
+ 0, SLAB_PANIC | SLAB_HWCACHE_ALIGN, NULL);
trie_leaf_kmem = kmem_cache_create("ip_fib_trie",
max(sizeof(struct leaf),
sizeof(struct leaf_info)),
- 0, SLAB_PANIC, NULL);
+ 0, SLAB_PANIC | SLAB_HWCACHE_ALIGN, NULL);
}
struct fib_table *fib_trie_table(u32 id)
{
struct fib_table *tb;
- struct trie *t;
-
- tb = kmalloc(sizeof(struct fib_table) + sizeof(struct trie),
- GFP_KERNEL);
- if (tb == NULL)
- return NULL;
-
- tb->tb_id = id;
- tb->tb_default = -1;
- tb->tb_num_default = 0;
-
- t = (struct trie *) tb->tb_data;
- memset(t, 0, sizeof(*t));
+ tb = fib_zalloc(sizeof(struct fib_table) + sizeof(struct trie));
+ if (tb) {
+ tb->tb_id = id;
+ tb->tb_default = -1;
+ }
return tb;
}
^ permalink raw reply related
* [PATCH iproute2 v2 0/3] CAN Filter/Classifier
From: Marc Kleine-Budde @ 2012-07-27 10:02 UTC (permalink / raw)
To: netdev; +Cc: linux-can, lartc, pisa, sojkam1, lisovy
Hello,
I'm reposting Rostislav's iproute2 patches, as Stephen requested,
during the v3.6 merge window with the corresponding kernel patches
already applied.
Changes since v1:
- use can.h generated by 'make headers_install' (tnx Stephen)
- remove some trailing whitespace
Now Rostislav original introduction message:
---
This classifier classifies CAN frames (AF_CAN) according to their
identifiers. This functionality can not be easily achieved with
existing classifiers, such as u32. This classifier can be used
with any available qdisc and it is able to classify both SFF
or EFF frames.
The filtering rules for EFF frames are stored in an array, which
is traversed during classification. A bitmap is used to store SFF
rules -- one bit for each ID.
More info about the project:
http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
---
The following changes since commit fa1f7441a94670ecf5cbf8eb2ee19173437b5127:
Remove reference to multipath algorithms in usage (2012-07-26 16:12:20 -0700)
are available in the git repository at:
git://gitorious.org/linux-can/iproute2.git for-stephen
for you to fetch changes up to 1a83c82569763968200d2cabdf8f5bcbe7940f9b:
CAN Filter/Classifier -- Documentation (2012-07-27 11:26:06 +0200)
----------------------------------------------------------------
Rostislav Lisovy (3):
Add missing can.h
CAN Filter/Classifier -- Source code
CAN Filter/Classifier -- Documentation
include/linux/can.h | 161 ++++++++++++++++++++++++++++++++
include/linux/pkt_cls.h | 10 ++
man/man8/tc-can.8 | 97 +++++++++++++++++++
tc/Makefile | 1 +
tc/f_can.c | 237 +++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 506 insertions(+)
create mode 100644 include/linux/can.h
create mode 100644 man/man8/tc-can.8
create mode 100644 tc/f_can.c
^ permalink raw reply
* [PATCH iproute2 v2 1/3] Add missing can.h
From: Marc Kleine-Budde @ 2012-07-27 10:02 UTC (permalink / raw)
To: netdev; +Cc: linux-can, lartc, pisa, sojkam1, lisovy, Marc Kleine-Budde
In-Reply-To: <1343383363-6174-1-git-send-email-mkl@pengutronix.de>
From: Rostislav Lisovy <lisovy@gmail.com>
This patch imports the can.h generated from linux kernel (v3.6 merge
window - v3.5-6970-g25918f9) with 'make headers_install'. It contains
defines necessary for working with AF_CAN packets.
Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
[mkl: use 'make headers_install' in current kernel]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Changes since v1:
- use can.h generated by 'make headers_install' (tnx Stephen)
include/linux/can.h | 161 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 161 insertions(+)
create mode 100644 include/linux/can.h
diff --git a/include/linux/can.h b/include/linux/can.h
new file mode 100644
index 0000000..018055e
--- /dev/null
+++ b/include/linux/can.h
@@ -0,0 +1,161 @@
+/*
+ * linux/can.h
+ *
+ * Definitions for CAN network layer (socket addr / CAN frame / CAN filter)
+ *
+ * Authors: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ * Urs Thuermann <urs.thuermann@volkswagen.de>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ */
+
+#ifndef CAN_H
+#define CAN_H
+
+#include <linux/types.h>
+#include <linux/socket.h>
+
+/* controller area network (CAN) kernel definitions */
+
+/* special address description flags for the CAN_ID */
+#define CAN_EFF_FLAG 0x80000000U /* EFF/SFF is set in the MSB */
+#define CAN_RTR_FLAG 0x40000000U /* remote transmission request */
+#define CAN_ERR_FLAG 0x20000000U /* error message frame */
+
+/* valid bits in CAN ID for frame formats */
+#define CAN_SFF_MASK 0x000007FFU /* standard frame format (SFF) */
+#define CAN_EFF_MASK 0x1FFFFFFFU /* extended frame format (EFF) */
+#define CAN_ERR_MASK 0x1FFFFFFFU /* omit EFF, RTR, ERR flags */
+
+/*
+ * Controller Area Network Identifier structure
+ *
+ * bit 0-28 : CAN identifier (11/29 bit)
+ * bit 29 : error message frame flag (0 = data frame, 1 = error message)
+ * bit 30 : remote transmission request flag (1 = rtr frame)
+ * bit 31 : frame format flag (0 = standard 11 bit, 1 = extended 29 bit)
+ */
+typedef __u32 canid_t;
+
+#define CAN_SFF_ID_BITS 11
+#define CAN_EFF_ID_BITS 29
+
+/*
+ * Controller Area Network Error Message Frame Mask structure
+ *
+ * bit 0-28 : error class mask (see include/linux/can/error.h)
+ * bit 29-31 : set to zero
+ */
+typedef __u32 can_err_mask_t;
+
+/* CAN payload length and DLC definitions according to ISO 11898-1 */
+#define CAN_MAX_DLC 8
+#define CAN_MAX_DLEN 8
+
+/* CAN FD payload length and DLC definitions according to ISO 11898-7 */
+#define CANFD_MAX_DLC 15
+#define CANFD_MAX_DLEN 64
+
+/**
+ * struct can_frame - basic CAN frame structure
+ * @can_id: CAN ID of the frame and CAN_*_FLAG flags, see canid_t definition
+ * @can_dlc: frame payload length in byte (0 .. 8) aka data length code
+ * N.B. the DLC field from ISO 11898-1 Chapter 8.4.2.3 has a 1:1
+ * mapping of the 'data length code' to the real payload length
+ * @data: CAN frame payload (up to 8 byte)
+ */
+struct can_frame {
+ canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
+ __u8 can_dlc; /* frame payload length in byte (0 .. CAN_MAX_DLEN) */
+ __u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));
+};
+
+/*
+ * defined bits for canfd_frame.flags
+ *
+ * As the default for CAN FD should be to support the high data rate in the
+ * payload section of the frame (HDR) and to support up to 64 byte in the
+ * data section (EDL) the bits are only set in the non-default case.
+ * Btw. as long as there's no real implementation for CAN FD network driver
+ * these bits are only preliminary.
+ *
+ * RX: NOHDR/NOEDL - info about received CAN FD frame
+ * ESI - bit from originating CAN controller
+ * TX: NOHDR/NOEDL - control per-frame settings if supported by CAN controller
+ * ESI - bit is set by local CAN controller
+ */
+#define CANFD_NOHDR 0x01 /* frame without high data rate */
+#define CANFD_NOEDL 0x02 /* frame without extended data length */
+#define CANFD_ESI 0x04 /* error state indicator */
+
+/**
+ * struct canfd_frame - CAN flexible data rate frame structure
+ * @can_id: CAN ID of the frame and CAN_*_FLAG flags, see canid_t definition
+ * @len: frame payload length in byte (0 .. CANFD_MAX_DLEN)
+ * @flags: additional flags for CAN FD
+ * @__res0: reserved / padding
+ * @__res1: reserved / padding
+ * @data: CAN FD frame payload (up to CANFD_MAX_DLEN byte)
+ */
+struct canfd_frame {
+ canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
+ __u8 len; /* frame payload length in byte */
+ __u8 flags; /* additional flags for CAN FD */
+ __u8 __res0; /* reserved / padding */
+ __u8 __res1; /* reserved / padding */
+ __u8 data[CANFD_MAX_DLEN] __attribute__((aligned(8)));
+};
+
+#define CAN_MTU (sizeof(struct can_frame))
+#define CANFD_MTU (sizeof(struct canfd_frame))
+
+/* particular protocols of the protocol family PF_CAN */
+#define CAN_RAW 1 /* RAW sockets */
+#define CAN_BCM 2 /* Broadcast Manager */
+#define CAN_TP16 3 /* VAG Transport Protocol v1.6 */
+#define CAN_TP20 4 /* VAG Transport Protocol v2.0 */
+#define CAN_MCNET 5 /* Bosch MCNet */
+#define CAN_ISOTP 6 /* ISO 15765-2 Transport Protocol */
+#define CAN_NPROTO 7
+
+#define SOL_CAN_BASE 100
+
+/**
+ * struct sockaddr_can - the sockaddr structure for CAN sockets
+ * @can_family: address family number AF_CAN.
+ * @can_ifindex: CAN network interface index.
+ * @can_addr: protocol specific address information
+ */
+struct sockaddr_can {
+ __kernel_sa_family_t can_family;
+ int can_ifindex;
+ union {
+ /* transport protocol class address information (e.g. ISOTP) */
+ struct { canid_t rx_id, tx_id; } tp;
+
+ /* reserved for future CAN protocols address information */
+ } can_addr;
+};
+
+/**
+ * struct can_filter - CAN ID based filter in can_register().
+ * @can_id: relevant bits of CAN ID which are not masked out.
+ * @can_mask: CAN mask (see description)
+ *
+ * Description:
+ * A filter matches, when
+ *
+ * <received_can_id> & mask == can_id & mask
+ *
+ * The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
+ * filter for error message frames (CAN_ERR_FLAG bit set in mask).
+ */
+struct can_filter {
+ canid_t can_id;
+ canid_t can_mask;
+};
+
+#define CAN_INV_FILTER 0x20000000U /* to be set in can_filter.can_id */
+
+#endif /* CAN_H */
--
1.7.10
^ permalink raw reply related
* [PATCH iproute2 v2 2/3] CAN Filter/Classifier -- Source code
From: Marc Kleine-Budde @ 2012-07-27 10:02 UTC (permalink / raw)
To: netdev; +Cc: linux-can, lartc, pisa, sojkam1, lisovy, Marc Kleine-Budde
In-Reply-To: <1343383363-6174-1-git-send-email-mkl@pengutronix.de>
From: Rostislav Lisovy <lisovy@gmail.com>
This classifier classifies CAN frames (AF_CAN) according to their
identifiers. This functionality can not be easily achieved with
existing classifiers, such as u32. This classifier can be used
with any available qdisc and it is able to classify both SFF
or EFF frames.
The filtering rules for EFF frames are stored in an array, which
is traversed during classification. A bitmap is used to store SFF
rules -- one bit for each ID.
More info about the project:
http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Changes since v1:
- remove black line at end of file
include/linux/pkt_cls.h | 10 ++
tc/Makefile | 1 +
tc/f_can.c | 237 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 248 insertions(+)
create mode 100644 tc/f_can.c
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index defbde2..83f9241 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -375,6 +375,16 @@ enum {
#define TCA_BASIC_MAX (__TCA_BASIC_MAX - 1)
+/* CAN filter */
+
+enum {
+ TCA_CANFLTR_UNSPEC,
+ TCA_CANFLTR_CLASSID,
+ TCA_CANFLTR_RULES,
+ __TCA_CANFLTR_MAX
+};
+
+#define TCA_CANFLTR_MAX (__TCA_CANFLTR_MAX - 1)
/* Cgroup classifier */
diff --git a/tc/Makefile b/tc/Makefile
index 64d93ad..1281568 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -22,6 +22,7 @@ TCMODULES += f_u32.o
TCMODULES += f_route.o
TCMODULES += f_fw.o
TCMODULES += f_basic.o
+TCMODULES += f_can.o
TCMODULES += f_flow.o
TCMODULES += f_cgroup.o
TCMODULES += q_dsmark.o
diff --git a/tc/f_can.c b/tc/f_can.c
new file mode 100644
index 0000000..531cf91
--- /dev/null
+++ b/tc/f_can.c
@@ -0,0 +1,237 @@
+/*
+ * f_can.c Filter for CAN packets
+ *
+ * This program is free software; you can distribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Idea: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ * Copyright: (c) 2011 Czech Technical University in Prague
+ * (c) 2011 Volkswagen Group Research
+ * Authors: Michal Sojka <sojkam1@fel.cvut.cz>
+ * Pavel Pisa <pisa@cmp.felk.cvut.cz>
+ * Rostislav Lisovy <lisovy@gmail.cz>
+ * Funded by: Volkswagen Group Research
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <syslog.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <string.h>
+#include <linux/if.h>
+#include <limits.h>
+#include <inttypes.h>
+#include "utils.h"
+#include "tc_util.h"
+#include "linux/can.h"
+
+#define RULES_SIZE 128 /* Maximum number of rules sent via the
+ netlink message during creation/configuration */
+
+
+static void canfltr_explain(void)
+{
+ fprintf(stderr, "Usage: ... can [ MATCHSPEC ] [ flowid FLOWID ]\n"
+ "\n"
+ "Where: MATCHSPEC := { sffid FILTERID | effid FILTERID |\n"
+ " MATCHSPEC ... }\n"
+ " FILTERID := CANID[:MASK]\n"
+ "\n"
+ "NOTE: CLASSID, CANID, MASK is parsed as hexadecimal input.\n");
+}
+
+static int canfltr_parse_opt(struct filter_util *qu, char *handle,
+ int argc, char **argv, struct nlmsghdr *n)
+{
+ struct tcmsg *t = NLMSG_DATA(n);
+ struct rtattr *tail;
+ struct can_filter canfltr_rules[RULES_SIZE];
+ int rules_count = 0;
+ long h = 0;
+ canid_t can_id;
+ canid_t can_mask;
+
+ if (!argc)
+ return 0;
+
+ if (handle) {
+ h = strtol(handle, NULL, 0);
+ if (h == LONG_MIN || h == LONG_MAX) {
+ fprintf(stderr, "Illegal handle \"%s\", must be numeric.\n",
+ handle);
+ return -1;
+ }
+ }
+
+ t->tcm_handle = h;
+
+ tail = NLMSG_TAIL(n);
+ addattr_l(n, MAX_MSG, TCA_OPTIONS, NULL, 0);
+
+ while (argc > 0) {
+ if (matches(*argv, "sffid") == 0) {
+ /* parse SFF CAN ID optionally with mask */
+ if (rules_count >= RULES_SIZE) {
+ fprintf(stderr, "Too much rules on input. "
+ "Maximum number of rules is: %d\n",
+ RULES_SIZE);
+ return -1;
+ }
+
+ NEXT_ARG();
+
+ if (sscanf(*argv, "%"SCNx32 ":" "%"SCNx32,
+ &can_id, &can_mask) != 2) {
+ if (sscanf(*argv, "%"SCNx32, &can_id) != 1) {
+ fprintf(stderr, "Improperly formed CAN "
+ "ID & mask '%s'\n", *argv);
+ return -1;
+ } else
+ can_mask = CAN_SFF_MASK;
+ }
+
+ /* we do not support extra handling for RTR frames
+ due to the bitmap approach */
+ if (can_id & ~CAN_SFF_MASK) {
+ fprintf(stderr, "ID 0x%lx exceeded standard CAN ID range.\n",
+ (unsigned long)can_id);
+ return -1;
+ }
+
+ canfltr_rules[rules_count].can_id = can_id;
+ canfltr_rules[rules_count].can_mask =
+ (can_mask & CAN_SFF_MASK);
+ rules_count++;
+
+ } else if (matches(*argv, "effid") == 0) {
+ /* parse EFF CAN ID optionally with mask */
+ if (rules_count >= RULES_SIZE) {
+ fprintf(stderr, "Too much rules on input. "
+ "Maximum number of rules is: %d\n",
+ RULES_SIZE);
+ return -1;
+ }
+
+ NEXT_ARG();
+
+ if (sscanf(*argv, "%"SCNx32 ":" "%"SCNx32, &can_id, &can_mask) != 2) {
+ if (sscanf(*argv, "%"SCNx32, &can_id) != 1) {
+ fprintf(stderr, "Improperly formed CAN ID & mask '%s'\n", *argv);
+ return -1;
+ } else
+ can_mask = CAN_EFF_MASK;
+ }
+
+ if (can_id & ~CAN_EFF_MASK) {
+ fprintf(stderr, "ID 0x%lx exceeded extended CAN ID range.",
+ (unsigned long)can_id);
+ return -1;
+ }
+
+ canfltr_rules[rules_count].can_id =
+ can_id | CAN_EFF_FLAG;
+ canfltr_rules[rules_count].can_mask =
+ (can_mask & CAN_EFF_MASK) | CAN_EFF_FLAG;
+ rules_count++;
+
+ } else if (matches(*argv, "classid") == 0 || strcmp(*argv, "flowid") == 0) {
+ unsigned handle;
+ NEXT_ARG();
+ if (get_tc_classid(&handle, *argv)) {
+ fprintf(stderr, "Illegal \"classid\"\n");
+ return -1;
+ }
+ addattr_l(n, MAX_MSG, TCA_CANFLTR_CLASSID, &handle, 4);
+
+ } else if (strcmp(*argv, "help") == 0) {
+ canfltr_explain();
+ return -1;
+
+ } else {
+ fprintf(stderr, "What is \"%s\"?\n", *argv);
+ canfltr_explain();
+ return -1;
+ }
+ argc--; argv++;
+ }
+
+ addattr_l(n, MAX_MSG, TCA_CANFLTR_RULES, &canfltr_rules,
+ sizeof(struct can_filter) * rules_count);
+
+ tail->rta_len = (void *)NLMSG_TAIL(n) - (void *)tail;
+ return 0;
+}
+
+/* When "tc filter show dev XY" is executed, function canfltr_walk() (in
+ * kernel) is called (which calls canfltr_dump() for each instance of a
+ * filter) which sends information about each instance of a filter to
+ * userspace -- to this function which parses the message and prints it.
+ */
+static int canfltr_print_opt(struct filter_util *qu, FILE *f,
+ struct rtattr *opt, __u32 handle)
+{
+ struct rtattr *tb[TCA_CANFLTR_MAX+1];
+ struct can_filter *canfltr_rules = NULL;
+ int rules_count = 0;
+ int i;
+
+ if (opt == NULL)
+ return 0;
+
+ parse_rtattr_nested(tb, TCA_CANFLTR_MAX, opt);
+
+ if (handle)
+ fprintf(f, "handle 0x%x ", handle);
+
+
+ if (tb[TCA_BASIC_CLASSID]) {
+ SPRINT_BUF(b1); /* allocates buffer b1 */
+ fprintf(f, "flowid %s ",
+ sprint_tc_classid(*(__u32 *)RTA_DATA(tb[TCA_BASIC_CLASSID]), b1));
+ }
+
+ if (tb[TCA_CANFLTR_RULES]) {
+ if (RTA_PAYLOAD(tb[TCA_CANFLTR_RULES]) < sizeof(struct can_filter))
+ return -1;
+
+ canfltr_rules = RTA_DATA(tb[TCA_CANFLTR_RULES]);
+ rules_count = (RTA_PAYLOAD(tb[TCA_CANFLTR_RULES]) /
+ sizeof(struct can_filter));
+
+ for (i = 0; i < rules_count; i++) {
+ struct can_filter *pcfltr = &canfltr_rules[i];
+
+ if (pcfltr->can_id & CAN_EFF_FLAG) {
+ if (pcfltr->can_mask == (CAN_EFF_FLAG|CAN_EFF_MASK))
+ fprintf(f, "effid 0x%"PRIX32" ",
+ pcfltr->can_id & CAN_EFF_MASK);
+ else
+ fprintf(f, "effid 0x%"PRIX32":0x%"PRIX32" ",
+ pcfltr->can_id & CAN_EFF_MASK,
+ pcfltr->can_mask & CAN_EFF_MASK);
+ } else {
+ if (pcfltr->can_mask == CAN_SFF_MASK)
+ fprintf(f, "sffid 0x%"PRIX32" ",
+ pcfltr->can_id);
+ else
+ fprintf(f, "sffid 0x%"PRIX32":0x%"PRIX32" ",
+ pcfltr->can_id,
+ pcfltr->can_mask);
+ }
+ }
+ }
+
+ return 0;
+}
+
+struct filter_util can_filter_util = {
+ .id = "can",
+ .parse_fopt = canfltr_parse_opt,
+ .print_fopt = canfltr_print_opt,
+};
--
1.7.10
^ permalink raw reply related
* [PATCH iproute2 v2 3/3] CAN Filter/Classifier -- Documentation
From: Marc Kleine-Budde @ 2012-07-27 10:02 UTC (permalink / raw)
To: netdev; +Cc: linux-can, lartc, pisa, sojkam1, lisovy, Marc Kleine-Budde
In-Reply-To: <1343383363-6174-1-git-send-email-mkl@pengutronix.de>
From: Rostislav Lisovy <lisovy@gmail.com>
Manpage describing usage of CAN Filter.
Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Changes since v1:
- remove trailing whitespace
man/man8/tc-can.8 | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 97 insertions(+)
create mode 100644 man/man8/tc-can.8
diff --git a/man/man8/tc-can.8 b/man/man8/tc-can.8
new file mode 100644
index 0000000..d60e872
--- /dev/null
+++ b/man/man8/tc-can.8
@@ -0,0 +1,97 @@
+.TH CAN 8 "8 May 2012" "iproute2" "Linux"
+.SH NAME
+CAN \- Controller Area Network classifier
+.SH SYNOPSIS
+.B tc filter ... dev
+DEV
+.B parent
+CLASSID
+.B [ prio
+PRIORITY
+.B ] [ protocol can ] [ handle
+HANDLE
+.B ] can [
+MATCHSPEC
+.B ] [ flowid
+FLOWID
+.B ]
+
+.B CLASSID := major:minor
+.br
+.B FLOWID := major:minor
+.br
+.B MATCHSPEC := { sffid
+FILTERID
+.B | effid
+FILTERID
+.B | MATCHSPEC ... }
+.br
+.B FILTERID := canid[:mask]
+
+.BR CLASSID ,
+.BR FLOWID ,
+.BR canid
+and
+.B mask
+are parsed as hexadecimal input.
+
+
+.SH DESCRIPTION
+The CAN classifier may be used with any available
+.B qdisc
+on Controller Area Network (CAN) frames passed through AF_CAN
+networking subsystem. The classifier classifies CAN frames according
+to their identifiers. It can be used on CAN frames with both SFF or
+EFF identifiers.
+
+It is possible to add CAN classifier to any qdisc configured on any networking
+device, however it will ignore non-CAN packets.
+
+
+.SH CLASSIFICATION
+The filtering rules for EFF frames are stored in an array, which is traversed
+during classification. This means that the worst-case time needed for
+classification of EFF frames increases with the number of configured rules.
+
+The filter implements an optimization for matching SFF frames using a bitmap
+with one bit for every ID. With this optimization, the classification time
+for SFF frames is nearly constant independently of the number of rules.
+
+.SH EXAMPLE
+This example shows how to set
+.B prio qdisc
+with
+.B CAN
+classifier.
+
+.nf
+tc qdisc add dev can0 root handle 1: prio
+
+tc filter add dev can0 parent 1:0 prio 1 handle 0xa \\
+ can sffid 0x7ff:0xf flowid 1:1
+tc filter add dev can0 parent 1:0 prio 2 handle 0xb \\
+ can sffid 0xC0:0x7ff effid 0x80:0x7ff flowid 1:2
+tc filter add dev can0 parent 1:0 prio 3 \\
+ can sffid 0x80:0x7ff flowid 1:2
+tc filter add dev can0 parent 1:0 prio 4 \\
+ can sffid 0x0:0x0 effid 0x0:0x0 flowid 1:3
+.fi
+
+
+.SH BUGS
+The maximum number or rules passed from
+.BR tc(8)
+utility to CAN classifier is fixed. The limit is set at compilation time
+(default is 128).
+
+
+.SH SEE ALSO
+.BR tc(8)
+
+
+.SH AUTHORS
+Michal Sojka <sojkam1@fel.cvut.cz>, Pavel Pisa <pisa@cmp.felk.cvut.cz>,
+Rostislav Lisovy <lisovy@gmail.cz>.
+
+This manpage maintained by Rostislav Lisovy <lisovy@gmail.com>
+
--
1.7.10
^ permalink raw reply related
* RE: [PATCH 1/2] iproute: Add magic cookie to route dump file
From: David Laight @ 2012-07-27 10:46 UTC (permalink / raw)
To: Pavel Emelyanov, Stephen Hemminger, Linux Netdev List
In-Reply-To: <50121F4D.8090606@parallels.com>
> 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.
Wouldn't a hash/checksum be useful as well?
Especially if it uneditable data.
David
^ permalink raw reply
* Re: [PATCH v2 0/7] TCP Fast Open client
From: Michael Kerrisk @ 2012-07-27 11:42 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: davem, hkchu, edumazet, ncardwell, sivasankar, netdev
In-Reply-To: <1342645307-17772-1-git-send-email-ycheng@google.com>
Yuchung,
On Wed, Jul 18, 2012 at 11:01 PM, Yuchung Cheng <ycheng@google.com> wrote:
> ChangeLog since v1:
> - Reduce tons of code by storing Fast Open stats in the TCP metrics :)
> - Clarify the purpose of using an experimental option in patch 1/7
>
> This patch series implement the client functionality of TCP Fast Open.
> TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
> packets and consumed by the receiving end during the initial connection
> handshake, thus providing a saving of up to one full round trip time (RTT)
> compared to standard TCP requiring a three-way handshake (3WHS) to
> complete before data can be exchanged.
>
> The protocol change is detailed in the IETF internet draft at
> http://www.ietf.org/id/draft-ietf-tcpm-fastopen-00.txt . The research
This URL appears to be invalid. I assume the following is the correct
current version:
http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-01
?
Is there some sample client and server userspace test code available?
Thanks,
Michael
--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
^ 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