* Re: [PATCH 5/5] ss: Show inet and unix sockets' shutdown state
From: Stephen Hemminger @ 2012-10-25 15:52 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Linux Netdev List
In-Reply-To: <50893E14.60001@parallels.com>
On Thu, 25 Oct 2012 17:26:44 +0400
Pavel Emelyanov <xemul@parallels.com> wrote:
> To see this we need kernel >=3.7 with _SHUTDOWN nlarrts in diag messages.
> The output will look like arrows at the end of each line, like this:
>
> ESTAB 0 0 127.0.0.1:41705 127.0.0.1:12345 ino:143321 sk:ffff88003a8cea00 -->
> ESTAB 0 0 127.0.0.1:46925 127.0.0.1:12346 ino:143322 sk:ffff88003a8ce4c0 <--
> ESTAB 0 0 127.0.0.1:51678 127.0.0.1:12347 ino:143323 sk:ffff88003a8cdf80 ---
> ESTAB 0 0 127.0.0.1:46911 127.0.0.1:12348 ino:143324 sk:ffff88003b7f05c0 <->
>
> for SHUT_RD, SHUT_WR, SHUT_RDWR and non-shutdown sockets respectively.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
>
> ---
> include/linux/inet_diag.h | 3 ++-
> include/linux/unix_diag.h | 1 +
> misc/ss.c | 26 ++++++++++++++++++++------
> 3 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/inet_diag.h b/include/linux/inet_diag.h
> index 8c469af..bbde90f 100644
> --- a/include/linux/inet_diag.h
> +++ b/include/linux/inet_diag.h
> @@ -109,9 +109,10 @@ enum {
> INET_DIAG_TOS,
> INET_DIAG_TCLASS,
> INET_DIAG_SKMEMINFO,
> + INET_DIAG_SHUTDOWN,
> };
Since this requires 3.8 or later kernel, please resubmit this
patch during that merge window.
^ permalink raw reply
* Re: switching network namespace midway
From: Benjamin LaHaise @ 2012-10-25 15:59 UTC (permalink / raw)
To: rsa; +Cc: Eric W. Biederman, netdev
In-Reply-To: <CAFaHj6Ey4vzXskvsKB_dG4fKGsn4X5oCF3N0YpGskiSaXrGSOw@mail.gmail.com>
On Thu, Oct 25, 2012 at 11:29:34AM -0400, rsa wrote:
> Hi Ben
> For L2TP that should work very well. But, with other tunnel types like GRE etc.
> route lookups have to be done first in the inner and then outer. It
> makes it easier
> to keep keep the tunnel in the inner namespace in such cases. right?
I've read IPv4 gre code, and it appears to do the right thing on rx, but it
does *not* appear to handle namespaces correctly on transmit. In general,
I would expect pretty much all code to get namespace handling correct for
the rx case. I'll have a closer look at fixing this tomorrow if nobody else
beats me to it.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [PATCH iproute2] iplink: Added support for the kernel IPoIB RTNL ops
From: Stephen Hemminger @ 2012-10-25 16:02 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev, Patrick McHardy
In-Reply-To: <1351177079-9052-1-git-send-email-ogerlitz@mellanox.com>
On Thu, 25 Oct 2012 16:57:59 +0200
Or Gerlitz <ogerlitz@mellanox.com> wrote:
> Added support to ipoib rtnl ops through which one can create, configure,
> query and delete IPoIB devices, for example
>
> $ ip link add link ib0.8001 name ib0.8001 type ipoib pkey 0x8001
> $ ip link add link ib0.1 name ib0.1 type ipoib mode connected
> $ ip --details link show dev ib0.1
>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Applied. Thanks for remembering the man page update as well.
^ permalink raw reply
* Re: [PATCH iproute2 2/2] ip: remove NLM_F_EXCL in case of ECMPv6 routes
From: Stephen Hemminger @ 2012-10-25 16:06 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, joe, bernat, eric.dumazet, yoshfuji, davem
In-Reply-To: <1350996176-4000-2-git-send-email-nicolas.dichtel@6wind.com>
On Tue, 23 Oct 2012 14:42:56 +0200
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> ECMPv6 routes are added each one after the other by the kernel, so we should
> avoid to set the flag NLM_F_EXCL.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> ip/iproute.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/ip/iproute.c b/ip/iproute.c
> index c60156f..799a70e 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -694,8 +694,11 @@ int parse_nexthops(struct nlmsghdr *n, struct rtmsg *r, int argc, char **argv)
> rtnh = RTNH_NEXT(rtnh);
> }
>
> - if (rta->rta_len > RTA_LENGTH(0))
> + if (rta->rta_len > RTA_LENGTH(0)) {
> addattr_l(n, 1024, RTA_MULTIPATH, RTA_DATA(rta), RTA_PAYLOAD(rta));
> + if (r->rtm_family == AF_INET6)
> + n->nlmsg_flags &= ~NLM_F_EXCL;
> + }
> return 0;
> }
>
Shouldn't this be true for multipath IPv4 as well?
^ permalink raw reply
* Re: [PATCH iproute2 1/2] ip: fix "ip -6 route add ... nexthop"
From: Stephen Hemminger @ 2012-10-25 16:08 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, joe, bernat, eric.dumazet, yoshfuji, davem
In-Reply-To: <1350996176-4000-1-git-send-email-nicolas.dichtel@6wind.com>
On Tue, 23 Oct 2012 14:42:55 +0200
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> From: Vincent Bernat <bernat@luffy.cx>
>
> IPv6 multipath routes were not accepted by "ip route" because an IPv4
> address was expected for each gateway. Use `get_addr()` instead of
> `get_addr32()`.
>
> Signed-off-by: Vincent Bernat <bernat@luffy.cx>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Looks good. Applied.
^ permalink raw reply
* Re: switching network namespace midway
From: Eric W. Biederman @ 2012-10-25 16:15 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: rsa, netdev
In-Reply-To: <20121025155927.GI15034@kvack.org>
Benjamin LaHaise <bcrl@kvack.org> writes:
> On Thu, Oct 25, 2012 at 11:29:34AM -0400, rsa wrote:
>> Hi Ben
>> For L2TP that should work very well. But, with other tunnel types like GRE etc.
>> route lookups have to be done first in the inner and then outer. It
>> makes it easier
>> to keep keep the tunnel in the inner namespace in such cases. right?
>
> I've read IPv4 gre code, and it appears to do the right thing on rx, but it
> does *not* appear to handle namespaces correctly on transmit. In general,
> I would expect pretty much all code to get namespace handling correct for
> the rx case. I'll have a closer look at fixing this tomorrow if nobody else
> beats me to it.
It will be interesting to see what you come up with.
Eric
^ permalink raw reply
* Re: [PATCH iproute2 2/2] ip: remove NLM_F_EXCL in case of ECMPv6 routes
From: Nicolas Dichtel @ 2012-10-25 16:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, joe, bernat, eric.dumazet, yoshfuji, davem
In-Reply-To: <20121025090628.25e484d1@nehalam.linuxnetplumber.net>
Le 25/10/2012 18:06, Stephen Hemminger a écrit :
> On Tue, 23 Oct 2012 14:42:56 +0200
> Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>
>> ECMPv6 routes are added each one after the other by the kernel, so we should
>> avoid to set the flag NLM_F_EXCL.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> ---
>> ip/iproute.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/ip/iproute.c b/ip/iproute.c
>> index c60156f..799a70e 100644
>> --- a/ip/iproute.c
>> +++ b/ip/iproute.c
>> @@ -694,8 +694,11 @@ int parse_nexthops(struct nlmsghdr *n, struct rtmsg *r, int argc, char **argv)
>> rtnh = RTNH_NEXT(rtnh);
>> }
>>
>> - if (rta->rta_len > RTA_LENGTH(0))
>> + if (rta->rta_len > RTA_LENGTH(0)) {
>> addattr_l(n, 1024, RTA_MULTIPATH, RTA_DATA(rta), RTA_PAYLOAD(rta));
>> + if (r->rtm_family == AF_INET6)
>> + n->nlmsg_flags &= ~NLM_F_EXCL;
>> + }
>> return 0;
>> }
>>
>
> Shouldn't this be true for multipath IPv4 as well?
>
In IPv4, the message is treating in one shot, because all nexthops are added in
the route. In IPv6, each nexthop is added like a single route and then they are
linked together.
^ permalink raw reply
* Re: switching network namespace midway
From: Stephen Hemminger @ 2012-10-25 16:21 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Eric W. Biederman, rsa, netdev
In-Reply-To: <20121025143811.GH15034@kvack.org>
I noticed that the L2TP sockets are not being moved to the correct name
space.
Something like this is probably needed.
--- a/net/l2tp/l2tp_core.c 2012-10-25 09:11:15.691271882 -0700
+++ b/net/l2tp/l2tp_core.c 2012-10-25 09:18:58.746621418 -0700
@@ -1357,7 +1357,10 @@ static void l2tp_tunnel_free(struct l2tp
* userspace. This is used for static tunnels where there is no
* managing L2TP daemon.
*/
-static int l2tp_tunnel_sock_create(u32 tunnel_id, u32 peer_tunnel_id, struct l2tp_tunnel_cfg *cfg, struct socket **sockp)
+static int l2tp_tunnel_sock_create(struct net *net,
+ u32 tunnel_id, u32 peer_tunnel_id,
+ struct l2tp_tunnel_cfg *cfg,
+ struct socket **sockp)
{
int err = -EINVAL;
struct sockaddr_in udp_addr;
@@ -1372,11 +1375,12 @@ static int l2tp_tunnel_sock_create(u32 t
case L2TP_ENCAPTYPE_UDP:
#if IS_ENABLED(CONFIG_IPV6)
if (cfg->local_ip6 && cfg->peer_ip6) {
- err = sock_create(AF_INET6, SOCK_DGRAM, 0, sockp);
+ err = sock_create_kern(AF_INET6, SOCK_DGRAM, 0, sockp);
if (err < 0)
goto out;
sock = *sockp;
+ sk_change(sock->sk, net);
memset(&udp6_addr, 0, sizeof(udp6_addr));
udp6_addr.sin6_family = AF_INET6;
@@ -1400,11 +1404,12 @@ static int l2tp_tunnel_sock_create(u32 t
} else
#endif
{
- err = sock_create(AF_INET, SOCK_DGRAM, 0, sockp);
+ err = sock_create_kern(AF_INET, SOCK_DGRAM, 0, sockp);
if (err < 0)
goto out;
sock = *sockp;
+ sk_change(sock->sk, net);
memset(&udp_addr, 0, sizeof(udp_addr));
udp_addr.sin_family = AF_INET;
@@ -1433,7 +1438,7 @@ static int l2tp_tunnel_sock_create(u32 t
case L2TP_ENCAPTYPE_IP:
#if IS_ENABLED(CONFIG_IPV6)
if (cfg->local_ip6 && cfg->peer_ip6) {
- err = sock_create(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP,
+ err = sock_create_kern(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP,
sockp);
if (err < 0)
goto out;
@@ -1462,12 +1467,13 @@ static int l2tp_tunnel_sock_create(u32 t
} else
#endif
{
- err = sock_create(AF_INET, SOCK_DGRAM, IPPROTO_L2TP,
+ err = sock_create_kern(AF_INET, SOCK_DGRAM, IPPROTO_L2TP,
sockp);
if (err < 0)
goto out;
sock = *sockp;
+ sk_change(sock->sk, net);
memset(&ip_addr, 0, sizeof(ip_addr));
ip_addr.l2tp_family = AF_INET;
@@ -1517,7 +1523,8 @@ int l2tp_tunnel_create(struct net *net,
* kernel socket.
*/
if (fd < 0) {
- err = l2tp_tunnel_sock_create(tunnel_id, peer_tunnel_id, cfg, &sock);
+ err = l2tp_tunnel_sock_create(net, tunnel_id, peer_tunnel_id,
+ cfg, &sock);
if (err < 0)
goto err;
} else {
^ permalink raw reply
* Re: [E1000-devel] dma_map_page and dma_map_single
From: Alexander Duyck @ 2012-10-25 16:21 UTC (permalink / raw)
To: ratheesh kannoth; +Cc: e1000-devel, netdev
In-Reply-To: <CAGZFCEGLhEp7+sD98-HjQFwbkVo70M2OWh29Y+yG5xwbm82obw@mail.gmail.com>
We use dma_map_single here because we have a virtual pointer and not a
page. If you look in the kernel at the file
include/asm-generic/dma-mapping-common.h you will see that
dma_map_single_attrs which is what ends up being called when we call
dma_map_single will convert the pointer to a page and then call
map_page. This way we don't have to place the overhead for the code
directly in our driver.
Thanks,
Alex
On 10/25/2012 01:58 AM, ratheesh kannoth wrote:
> Hi ,
>
> I was looking at tx_map ( igb-3.3.6 ) in igb driver. I could see that
> dma_map_single is used for first buffer and dma_map_page is used for
> the fragments.
>
> What is the real difference between these api ? we can replace
> dma_map_single with dma_map_page. then why we used dma_map_single
> here ?.
>
> Thanks,
> Ratheesh
>
^ permalink raw reply
* Re: [PATCH iproute2 2/2] ip: remove NLM_F_EXCL in case of ECMPv6 routes
From: Stephen Hemminger @ 2012-10-25 16:25 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, joe, bernat, eric.dumazet, yoshfuji, davem
In-Reply-To: <508966E1.2050205@6wind.com>
On Thu, 25 Oct 2012 18:20:49 +0200
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Le 25/10/2012 18:06, Stephen Hemminger a écrit :
> > On Tue, 23 Oct 2012 14:42:56 +0200
> > Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> >
> >> ECMPv6 routes are added each one after the other by the kernel, so we should
> >> avoid to set the flag NLM_F_EXCL.
> >>
> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >> ---
> >> ip/iproute.c | 5 ++++-
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/ip/iproute.c b/ip/iproute.c
> >> index c60156f..799a70e 100644
> >> --- a/ip/iproute.c
> >> +++ b/ip/iproute.c
> >> @@ -694,8 +694,11 @@ int parse_nexthops(struct nlmsghdr *n, struct rtmsg *r, int argc, char **argv)
> >> rtnh = RTNH_NEXT(rtnh);
> >> }
> >>
> >> - if (rta->rta_len > RTA_LENGTH(0))
> >> + if (rta->rta_len > RTA_LENGTH(0)) {
> >> addattr_l(n, 1024, RTA_MULTIPATH, RTA_DATA(rta), RTA_PAYLOAD(rta));
> >> + if (r->rtm_family == AF_INET6)
> >> + n->nlmsg_flags &= ~NLM_F_EXCL;
> >> + }
> >> return 0;
> >> }
> >>
> >
> > Shouldn't this be true for multipath IPv4 as well?
> >
> In IPv4, the message is treating in one shot, because all nexthops are added in
> the route. In IPv6, each nexthop is added like a single route and then they are
> linked together.
So it is a fundamental design flaw in how either v4 or v6 was implemented in
the kernel?
^ permalink raw reply
* Re: [PATCH iproute2 2/2] ip: remove NLM_F_EXCL in case of ECMPv6 routes
From: Nicolas Dichtel @ 2012-10-25 16:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, joe, bernat, eric.dumazet, yoshfuji, davem
In-Reply-To: <20121025092526.5bb0a7ca@nehalam.linuxnetplumber.net>
Le 25/10/2012 18:25, Stephen Hemminger a écrit :
> On Thu, 25 Oct 2012 18:20:49 +0200
> Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>
>> Le 25/10/2012 18:06, Stephen Hemminger a écrit :
>>> On Tue, 23 Oct 2012 14:42:56 +0200
>>> Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>>>
>>>> ECMPv6 routes are added each one after the other by the kernel, so we should
>>>> avoid to set the flag NLM_F_EXCL.
>>>>
>>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>>> ---
>>>> ip/iproute.c | 5 ++++-
>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/ip/iproute.c b/ip/iproute.c
>>>> index c60156f..799a70e 100644
>>>> --- a/ip/iproute.c
>>>> +++ b/ip/iproute.c
>>>> @@ -694,8 +694,11 @@ int parse_nexthops(struct nlmsghdr *n, struct rtmsg *r, int argc, char **argv)
>>>> rtnh = RTNH_NEXT(rtnh);
>>>> }
>>>>
>>>> - if (rta->rta_len > RTA_LENGTH(0))
>>>> + if (rta->rta_len > RTA_LENGTH(0)) {
>>>> addattr_l(n, 1024, RTA_MULTIPATH, RTA_DATA(rta), RTA_PAYLOAD(rta));
>>>> + if (r->rtm_family == AF_INET6)
>>>> + n->nlmsg_flags &= ~NLM_F_EXCL;
>>>> + }
>>>> return 0;
>>>> }
>>>>
>>>
>>> Shouldn't this be true for multipath IPv4 as well?
>>>
>> In IPv4, the message is treating in one shot, because all nexthops are added in
>> the route. In IPv6, each nexthop is added like a single route and then they are
>> linked together.
>
> So it is a fundamental design flaw in how either v4 or v6 was implemented in
> the kernel?
>
The way to manage route is just different. Maybe a patch in the kernel is more
appropriate:
From b4979c97f33bc41a0fa095751bfcc05de074afec Mon Sep 17 00:00:00 2001
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 25 Oct 2012 18:45:47 +0200
Subject: [PATCH] ipv6/multipath: remove flag NLM_F_EXCL after the first
nexthop
fib6_add_rt2node() will reject the nexthop if this flag is set, so
we perform the check only for the first nexthop.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/route.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c42650c..9c7b5d8 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2449,6 +2449,12 @@ beginning:
goto beginning;
}
}
+ /* Because each route is added like a single route we remove
+ * this flag after the first nexthop (if there is a collision,
+ * we have already fail to add the first nexthop:
+ * fib6_add_rt2node() has reject it).
+ */
+ cfg->fc_nlinfo.nlh->nlmsg_flags &= ~NLM_F_EXCL;
rtnh = rtnh_next(rtnh, &remaining);
}
--
1.7.12
^ permalink raw reply related
* Re: [PATCH 5/5] ss: Show inet and unix sockets' shutdown state
From: Eric Dumazet @ 2012-10-25 16:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Pavel Emelyanov, Linux Netdev List
In-Reply-To: <20121025085229.3aa43b68@nehalam.linuxnetplumber.net>
On Thu, 2012-10-25 at 08:52 -0700, Stephen Hemminger wrote:
> On Thu, 25 Oct 2012 17:26:44 +0400
> Pavel Emelyanov <xemul@parallels.com> wrote:
>
> > To see this we need kernel >=3.7 with _SHUTDOWN nlarrts in diag messages.
> > The output will look like arrows at the end of each line, like this:
> >
> > ESTAB 0 0 127.0.0.1:41705 127.0.0.1:12345 ino:143321 sk:ffff88003a8cea00 -->
> > ESTAB 0 0 127.0.0.1:46925 127.0.0.1:12346 ino:143322 sk:ffff88003a8ce4c0 <--
> > ESTAB 0 0 127.0.0.1:51678 127.0.0.1:12347 ino:143323 sk:ffff88003a8cdf80 ---
> > ESTAB 0 0 127.0.0.1:46911 127.0.0.1:12348 ino:143324 sk:ffff88003b7f05c0 <->
> >
> > for SHUT_RD, SHUT_WR, SHUT_RDWR and non-shutdown sockets respectively.
> >
> > Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
> >
> > ---
> > include/linux/inet_diag.h | 3 ++-
> > include/linux/unix_diag.h | 1 +
> > misc/ss.c | 26 ++++++++++++++++++++------
> > 3 files changed, 23 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/inet_diag.h b/include/linux/inet_diag.h
> > index 8c469af..bbde90f 100644
> > --- a/include/linux/inet_diag.h
> > +++ b/include/linux/inet_diag.h
> > @@ -109,9 +109,10 @@ enum {
> > INET_DIAG_TOS,
> > INET_DIAG_TCLASS,
> > INET_DIAG_SKMEMINFO,
> > + INET_DIAG_SHUTDOWN,
> > };
>
> Since this requires 3.8 or later kernel, please resubmit this
> patch during that merge window.
> --
I am wondering what possibly could happen if applying this before ?
iproute2 should be non dependent on kernel version, we make sure to not
add regressions.
^ permalink raw reply
* Supporting more devices with dev_alloc_name()
From: Tom Parkin @ 2012-10-25 16:56 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
Hi list,
I've recently been trying to create large-scale L2TPv3 configurations
of up to 50,000 Ethernet pseudowires.
One of the limitations I've hit has been to do with dev_alloc_name().
By default, l2tp_eth uses "l2tpeth%d" for device names, which is
expanded by dev_alloc_name() into l2tpeth1, l2tpeth2, etc. However,
the algorithm dev_alloc_name() uses to derive the next free number for
this scheme is bounded by the number of bits in a single page. For
kernels/platforms with a 4kB page, this limits these "autoderived"
names to 32k.
In my testing I've been able to work around this by specifying
interface names during the bringup of the l2tpeth interfaces, thereby
bypassing dev_alloc_name() altogether. Using this approach I am able
to comfortably create 50k interfaces, even on fairly modest hardware.
But it seems a shame to have to do this; it would be much nicer if
the kernel were able to autogenerate names for more devices.
Is this something that would be worth my working on a patch for, or
would the increased code complexity be too great an overhead to
consider for such outlandish use-cases?
Thanks,
Tom
--
Tom Parkin
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [RFC] back on nf_tables (plus compatibility layer)
From: Pablo Neira Ayuso @ 2012-10-25 17:06 UTC (permalink / raw)
To: Netfilter Development Mailing list; +Cc: netdev
Hi,
I've been working for a while to recover nf_tables kernel patches and
to implement a compatibility layer so it can be used with existing
x_tables target/match extensions. These are the main reasons that
motivated me to follow this approach:
1) nf_tables already provides a netlink interface, which has been a
longstanding demand from users.
2) Provide a fast path to merge this into mainstream. We'll have both
iptables and nftables interfaces during some time in the Linux kernel,
then remove iptables infrastructure at some point. iptables scripts
would not break as we'll have the iptables emulation over nftables.
3) Regarding the compatibility layer: To provide a working command
line utility with the same syntax of iptables. The idea is that users
don't notice that they are working with the nf_tables kernel
infrastructure. We did that during the transition from ipchains to
iptables.
4) Several extensions for x_tables still need to be ported to
nf_tables. With the compatibility layer, we can use non-native
x_tables extensions with nf_tables until it fully provides a
replacement for all existing features.
5) The compatibility layer provides a way to hook existing x_tables
matches/targets with nftables. So we can use all existing features
from nftables until we provide native nftables expressions /
user-space code that replace them.
The compatibility layer has limitations to emulate struct ipt_entry,
hookmask, protocol and inversion passed to xt->checkentry(). But this
can be mostly workaround by relaxing some of the checking in
kernel-space that prevent users from doing stupid things (like trying
to use the TCPMSS target for non-TCP traffic / non-syn packets). In my
list, the affected targets are ECN, CLUSTERIP, TCPMSS, REJECT and CT.
I have some proposals on how to workaround those.
You can access the preliminary iptables over nftables code from:
http://1984.lsi.us.es/git/iptables-nftables/
The name of the utilities are xtables, xtables-save and
xtables-restore.
There are several missing features in that iptables over nftables
code: -Z, -R, -E, rule insertion at position and -f are not yet
working. IPv6 support is also still missing.
It requires this user-space library:
http://1984.lsi.us.es/git/libnftables/
And the following Linux kernel code with several experimental patches
of mine:
http://1984.lsi.us.es/git/nf-next/log/?h=nf_tables-experiments
I see several things that need to be improved in the nftables kernel
side:
1) Improve rule addition and deletion timing, currently it is not
very good compared to iptables. To improve deletions I think we
have to modify the current locking approach based on RCU. To improve
additions, we have to improve the unique handle allocation (probably
using a 64-bits handle number so we forget about wrap-arounds and we
just incrementally assign new handles).
2) No built-in nat and route tables. Better allow from user-space
configure one table with the nat / route property. If we provide
documentation on how to use them appropriately, I would not worry too
much if the user uses wrongly.
3) Add operation to obtain chain counters, following the same approach
of iptables (iterate over the entire rule-set and accumulate packets
and bytes, like in get_counters()).
4) Add native support for TRACE, it seems to be missing in nf_tables.
5) Changes to allow to add rules at positions and replace them, since
iptables allows this.
6) To speed up packet matching, we can compile nftables expressions to
some internal bytecode (that could be even compiled to native assembly
instructions like Eric Dumazet did for BPF).
Several of these things can be improved while we already have this in
mainline.
One final thing: nftables does not support atomic table commit. The
point here is if we really need this for the emulation utility or we
can live without that. Implementing atomic table replacement in
nftables is not trivial. I have hard time to find this commit table
feature useful.
That's all by now. By resolving most of these things and having the
compatibility layer ready, we should get nftables into mainstream
anytime soon IMO.
Comments welcome.
Regards.
^ permalink raw reply
* Re: [PATCH 5/5] ss: Show inet and unix sockets' shutdown state
From: Stephen Hemminger @ 2012-10-25 17:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Pavel Emelyanov, Linux Netdev List
In-Reply-To: <1351184010.6537.158.camel@edumazet-glaptop>
On Thu, 25 Oct 2012 18:53:30 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-10-25 at 08:52 -0700, Stephen Hemminger wrote:
> > On Thu, 25 Oct 2012 17:26:44 +0400
> > Pavel Emelyanov <xemul@parallels.com> wrote:
> >
> > > To see this we need kernel >=3.7 with _SHUTDOWN nlarrts in diag messages.
> > > The output will look like arrows at the end of each line, like this:
> > >
> > > ESTAB 0 0 127.0.0.1:41705 127.0.0.1:12345 ino:143321 sk:ffff88003a8cea00 -->
> > > ESTAB 0 0 127.0.0.1:46925 127.0.0.1:12346 ino:143322 sk:ffff88003a8ce4c0 <--
> > > ESTAB 0 0 127.0.0.1:51678 127.0.0.1:12347 ino:143323 sk:ffff88003a8cdf80 ---
> > > ESTAB 0 0 127.0.0.1:46911 127.0.0.1:12348 ino:143324 sk:ffff88003b7f05c0 <->
> > >
> > > for SHUT_RD, SHUT_WR, SHUT_RDWR and non-shutdown sockets respectively.
> > >
> > > Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
> > >
> > > ---
> > > include/linux/inet_diag.h | 3 ++-
> > > include/linux/unix_diag.h | 1 +
> > > misc/ss.c | 26 ++++++++++++++++++++------
> > > 3 files changed, 23 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/include/linux/inet_diag.h b/include/linux/inet_diag.h
> > > index 8c469af..bbde90f 100644
> > > --- a/include/linux/inet_diag.h
> > > +++ b/include/linux/inet_diag.h
> > > @@ -109,9 +109,10 @@ enum {
> > > INET_DIAG_TOS,
> > > INET_DIAG_TCLASS,
> > > INET_DIAG_SKMEMINFO,
> > > + INET_DIAG_SHUTDOWN,
> > > };
> >
> > Since this requires 3.8 or later kernel, please resubmit this
> > patch during that merge window.
> > --
>
> I am wondering what possibly could happen if applying this before ?
>
> iproute2 should be non dependent on kernel version, we make sure to not
> add regressions.
>
>
>
I don't want the stashed kernel headers to get out of date with kernel exported ones.
People who want to test early features are free to build their own pre-release versions.
^ permalink raw reply
* [PATCH] tilegx: fix some issues in the SW TSO support
From: Chris Metcalf @ 2012-10-25 17:25 UTC (permalink / raw)
To: netdev, linux-kernel
This change correctly computes the header length and data length in
the fragments to avoid a bug where we would end up with extremely
slow performance. Also adopt use of skb_frag_size() accessor.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Cc: stable@vger.kernel.org [v3.6]
---
drivers/net/ethernet/tile/tilegx.c | 35 +++++++++++++++++++----------------
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c b/drivers/net/ethernet/tile/tilegx.c
index 4e2a162..4e98100 100644
--- a/drivers/net/ethernet/tile/tilegx.c
+++ b/drivers/net/ethernet/tile/tilegx.c
@@ -1334,11 +1334,11 @@ static int tso_count_edescs(struct sk_buff *skb)
{
struct skb_shared_info *sh = skb_shinfo(skb);
unsigned int sh_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
- unsigned int data_len = skb->data_len + skb->hdr_len - sh_len;
+ unsigned int data_len = skb->len - sh_len;
unsigned int p_len = sh->gso_size;
long f_id = -1; /* id of the current fragment */
- long f_size = skb->hdr_len; /* size of the current fragment */
- long f_used = sh_len; /* bytes used from the current fragment */
+ long f_size = skb_headlen(skb) - sh_len; /* current fragment size */
+ long f_used = 0; /* bytes used from the current fragment */
long n; /* size of the current piece of payload */
int num_edescs = 0;
int segment;
@@ -1353,7 +1353,7 @@ static int tso_count_edescs(struct sk_buff *skb)
/* Advance as needed. */
while (f_used >= f_size) {
f_id++;
- f_size = sh->frags[f_id].size;
+ f_size = skb_frag_size(&sh->frags[f_id]);
f_used = 0;
}
@@ -1384,13 +1384,13 @@ static void tso_headers_prepare(struct sk_buff *skb, unsigned char *headers,
struct iphdr *ih;
struct tcphdr *th;
unsigned int sh_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
- unsigned int data_len = skb->data_len + skb->hdr_len - sh_len;
+ unsigned int data_len = skb->len - sh_len;
unsigned char *data = skb->data;
unsigned int ih_off, th_off, p_len;
unsigned int isum_seed, tsum_seed, id, seq;
long f_id = -1; /* id of the current fragment */
- long f_size = skb->hdr_len; /* size of the current fragment */
- long f_used = sh_len; /* bytes used from the current fragment */
+ long f_size = skb_headlen(skb) - sh_len; /* current fragment size */
+ long f_used = 0; /* bytes used from the current fragment */
long n; /* size of the current piece of payload */
int segment;
@@ -1405,7 +1405,7 @@ static void tso_headers_prepare(struct sk_buff *skb, unsigned char *headers,
isum_seed = ((0xFFFF - ih->check) +
(0xFFFF - ih->tot_len) +
(0xFFFF - ih->id));
- tsum_seed = th->check + (0xFFFF ^ htons(sh_len + data_len));
+ tsum_seed = th->check + (0xFFFF ^ htons(skb->len));
id = ntohs(ih->id);
seq = ntohl(th->seq);
@@ -1444,7 +1444,7 @@ static void tso_headers_prepare(struct sk_buff *skb, unsigned char *headers,
/* Advance as needed. */
while (f_used >= f_size) {
f_id++;
- f_size = sh->frags[f_id].size;
+ f_size = skb_frag_size(&sh->frags[f_id]);
f_used = 0;
}
@@ -1478,14 +1478,14 @@ static void tso_egress(struct net_device *dev, gxio_mpipe_equeue_t *equeue,
struct tile_net_priv *priv = netdev_priv(dev);
struct skb_shared_info *sh = skb_shinfo(skb);
unsigned int sh_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
- unsigned int data_len = skb->data_len + skb->hdr_len - sh_len;
+ unsigned int data_len = skb->len - sh_len;
unsigned int p_len = sh->gso_size;
gxio_mpipe_edesc_t edesc_head = { { 0 } };
gxio_mpipe_edesc_t edesc_body = { { 0 } };
long f_id = -1; /* id of the current fragment */
- long f_size = skb->hdr_len; /* size of the current fragment */
- long f_used = sh_len; /* bytes used from the current fragment */
- void *f_data = skb->data;
+ long f_size = skb_headlen(skb) - sh_len; /* current fragment size */
+ long f_used = 0; /* bytes used from the current fragment */
+ void *f_data = skb->data + sh_len;
long n; /* size of the current piece of payload */
unsigned long tx_packets = 0, tx_bytes = 0;
unsigned int csum_start;
@@ -1516,15 +1516,18 @@ static void tso_egress(struct net_device *dev, gxio_mpipe_equeue_t *equeue,
/* Egress the payload. */
while (p_used < p_len) {
+ void *va;
/* Advance as needed. */
while (f_used >= f_size) {
f_id++;
- f_size = sh->frags[f_id].size;
- f_used = 0;
+ f_size = skb_frag_size(&sh->frags[f_id]);
f_data = tile_net_frag_buf(&sh->frags[f_id]);
+ f_used = 0;
}
+ va = f_data + f_used;
+
/* Use bytes from the current fragment. */
n = p_len - p_used;
if (n > f_size - f_used)
@@ -1533,7 +1536,7 @@ static void tso_egress(struct net_device *dev, gxio_mpipe_equeue_t *equeue,
p_used += n;
/* Egress a piece of the payload. */
- edesc_body.va = va_to_tile_io_addr(f_data) + f_used;
+ edesc_body.va = va_to_tile_io_addr(va);
edesc_body.xfer_size = n;
edesc_body.bound = !(p_used < p_len);
gxio_mpipe_equeue_put_at(equeue, edesc_body, slot);
--
1.7.10.3
^ permalink raw reply related
* Regarding bottlenecks for high speed packet generation
From: Ajith Adapa @ 2012-10-25 17:46 UTC (permalink / raw)
To: netdev
Hi,
I am trying out a sample application written based on packet_mmap to
generate packets at line rates. I am using 3.4.10 kernel and a gigabit
nic card.
I have found some strange issues as mentioned below.
When I am transmitting packets sized 1500 bytes the socket buffers are
easily filled up eventhough if I increase the value of wmem_default
and wmem_max.
The memory I have allotted can fit around 14k packets of 1500 bytes
size. Is the NIC card not able to transmit them ?? How can I check it
??
I have even increased the Hardware tx queue size of NIC card from 256
to 4096 using ethtool.
Does traffic control causing any issue as I read it wont allow traffic bursts ?
Is there any way to find the major bottlenecks that would really cause
problems in high-speed packet generation.
Regards,
Ajith
^ permalink raw reply
* Re: Supporting more devices with dev_alloc_name()
From: Eric Dumazet @ 2012-10-25 17:50 UTC (permalink / raw)
To: Tom Parkin; +Cc: netdev
In-Reply-To: <20121025165632.GC7857@raven>
On Thu, 2012-10-25 at 17:56 +0100, Tom Parkin wrote:
> Hi list,
>
> I've recently been trying to create large-scale L2TPv3 configurations
> of up to 50,000 Ethernet pseudowires.
>
> One of the limitations I've hit has been to do with dev_alloc_name().
> By default, l2tp_eth uses "l2tpeth%d" for device names, which is
> expanded by dev_alloc_name() into l2tpeth1, l2tpeth2, etc. However,
> the algorithm dev_alloc_name() uses to derive the next free number for
> this scheme is bounded by the number of bits in a single page. For
> kernels/platforms with a 4kB page, this limits these "autoderived"
> names to 32k.
>
> In my testing I've been able to work around this by specifying
> interface names during the bringup of the l2tpeth interfaces, thereby
> bypassing dev_alloc_name() altogether. Using this approach I am able
> to comfortably create 50k interfaces, even on fairly modest hardware.
> But it seems a shame to have to do this; it would be much nicer if
> the kernel were able to autogenerate names for more devices.
>
> Is this something that would be worth my working on a patch for, or
> would the increased code complexity be too great an overhead to
> consider for such outlandish use-cases?
This issue was raised some ago, for the dummy device
modprobe dummy numdummies=33000
I guess each format (eg eth%d) could be attached/associated to an idr,
so that we can find the lowest available index very fast.
^ permalink raw reply
* Re: [PATCH] tilegx: fix some issues in the SW TSO support
From: Ben Hutchings @ 2012-10-25 17:51 UTC (permalink / raw)
To: Chris Metcalf; +Cc: netdev, linux-kernel
In-Reply-To: <201210251737.q9PHbgev032681@farm-0012.internal.tilera.com>
On Thu, 2012-10-25 at 13:25 -0400, Chris Metcalf wrote:
> This change correctly computes the header length and data length in
> the fragments to avoid a bug where we would end up with extremely
> slow performance. Also adopt use of skb_frag_size() accessor.
[...]
By the way, since you're doing soft-TSO you should probably set
net_device::gso_max_segs, as explained in:
commit 30b678d844af3305cda5953467005cebb5d7b687
Author: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon Jul 30 15:57:00 2012 +0000
net: Allow driver to limit number of GSO segments per skb
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 5/5] ss: Show inet and unix sockets' shutdown state
From: Eric Dumazet @ 2012-10-25 18:00 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Pavel Emelyanov, Linux Netdev List
In-Reply-To: <20121025100922.12ed2061@nehalam.linuxnetplumber.net>
On Thu, 2012-10-25 at 10:09 -0700, Stephen Hemminger wrote:
> I don't want the stashed kernel headers to get out of date with kernel exported ones.
>
> People who want to test early features are free to build their own pre-release versions.
> --
Have you considered an iproute2-next tree, it would really help us a
lot.
Just to be clear, were the patches 1-4 accepted ?
(UDP diag was added kernel in December 2011)
Thanks
^ permalink raw reply
* Re: Regarding bottlenecks for high speed packet generation
From: Daniel Borkmann @ 2012-10-25 18:04 UTC (permalink / raw)
To: Ajith Adapa; +Cc: netdev
In-Reply-To: <CADAe=+KJ2QuL7ZdrfDWQe8R1vF_r_bu3QBS-5kwZBgQ21QTMtg@mail.gmail.com>
On Thu, Oct 25, 2012 at 7:46 PM, Ajith Adapa <adapa.ajith@gmail.com> wrote:
> I am trying out a sample application written based on packet_mmap to
> generate packets at line rates. I am using 3.4.10 kernel and a gigabit
> nic card.
> I have found some strange issues as mentioned below.
>
> When I am transmitting packets sized 1500 bytes the socket buffers are
> easily filled up eventhough if I increase the value of wmem_default
> and wmem_max.
> The memory I have allotted can fit around 14k packets of 1500 bytes
> size. Is the NIC card not able to transmit them ?? How can I check it
> ??
> I have even increased the Hardware tx queue size of NIC card from 256
> to 4096 using ethtool.
>
> Does traffic control causing any issue as I read it wont allow traffic bursts ?
Actually in my experience not. On Gigabit Ethernet (depending on your
machine) you should be able to generate about 80k pps with 1500 byte
(e.g. with netsniff-ng's trafgen) having the default tc discipline.
> Is there any way to find the major bottlenecks that would really cause
> problems in high-speed packet generation.
Have you looked how much pps the kernel space pktgen can generate on
your machine with 1500 byte packets?
What tool do you use to measure this reported rate? Do you analyze
driver statistics from e.g. procfs, or do you use a libpcap-based tool
to measure the stuff (which you shouldn't since it could falsify your
stats)? How was your measurement setup?
^ permalink raw reply
* Re: [PATCH v1 4/5] cgroup: net_cls: Pass in task to sock_update_classid()
From: Tejun Heo @ 2012-10-25 18:11 UTC (permalink / raw)
To: Daniel Wagner
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, David S. Miller, Michael S. Tsirkin, Eric Dumazet,
Glauber Costa, Joe Perches, Neil Horman, Stanislav Kinsbursky
In-Reply-To: <1351174619-5096-5-git-send-email-wagi-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
On Thu, Oct 25, 2012 at 04:16:58PM +0200, Daniel Wagner wrote:
> From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
>
> sock_update_classid() assumes that the update operation always are
> applied on the current task. sock_update_classid() needs to know on
> which tasks to work on in order to be able to migrate task between
> cgroups using the struct cgroup_subsys attach() callback.
>
> Signed-off-by: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Cc: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> Cc: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
> Cc: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Cc: Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Cc: <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
1-4 look good to me. I have no idea about 5. :)
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] tilegx: fix some issues in the SW TSO support
From: Chris Metcalf @ 2012-10-25 18:16 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, linux-kernel
In-Reply-To: <1351187513.2662.9.camel@bwh-desktop.uk.solarflarecom.com>
On 10/25/2012 1:51 PM, Ben Hutchings wrote:
> On Thu, 2012-10-25 at 13:25 -0400, Chris Metcalf wrote:
>> This change correctly computes the header length and data length in
>> the fragments to avoid a bug where we would end up with extremely
>> slow performance. Also adopt use of skb_frag_size() accessor.
> [...]
>
> By the way, since you're doing soft-TSO you should probably set
> net_device::gso_max_segs, as explained in:
>
> commit 30b678d844af3305cda5953467005cebb5d7b687
> Author: Ben Hutchings <bhutchings@solarflare.com>
> Date: Mon Jul 30 15:57:00 2012 +0000
>
> net: Allow driver to limit number of GSO segments per skb
We currently have a hard limit of 2048 equeue entries (effectively,
segments) per interface. The commit message suggests 861 is the largest
number we're likely to see, so I think we're OK from a correctness point of
view. But, perhaps, we could end up with multiple cores trying to push
separate flows each with this tiny MSS issue, and they would then be
contending for the 2048 equeue entries, and performance might suffer. I
don't have a good instinct on what value we should choose to set here; I
see that sfc uses 100.
So, we could do nothing since it seems we're technically safe; we could say
2048 to be explicit; we could pick a random fraction of the full size to
help avoid contention effects, like 1024 or 512; or we could mimic sfc and
just say 100. What do you think?
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: Supporting more devices with dev_alloc_name()
From: Stephen Hemminger @ 2012-10-25 18:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Parkin, netdev
In-Reply-To: <1351187443.6537.184.camel@edumazet-glaptop>
On Thu, 25 Oct 2012 19:50:43 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-10-25 at 17:56 +0100, Tom Parkin wrote:
> > Hi list,
> >
> > I've recently been trying to create large-scale L2TPv3 configurations
> > of up to 50,000 Ethernet pseudowires.
> >
> > One of the limitations I've hit has been to do with dev_alloc_name().
> > By default, l2tp_eth uses "l2tpeth%d" for device names, which is
> > expanded by dev_alloc_name() into l2tpeth1, l2tpeth2, etc. However,
> > the algorithm dev_alloc_name() uses to derive the next free number for
> > this scheme is bounded by the number of bits in a single page. For
> > kernels/platforms with a 4kB page, this limits these "autoderived"
> > names to 32k.
> >
> > In my testing I've been able to work around this by specifying
> > interface names during the bringup of the l2tpeth interfaces, thereby
> > bypassing dev_alloc_name() altogether. Using this approach I am able
> > to comfortably create 50k interfaces, even on fairly modest hardware.
> > But it seems a shame to have to do this; it would be much nicer if
> > the kernel were able to autogenerate names for more devices.
> >
> > Is this something that would be worth my working on a patch for, or
> > would the increased code complexity be too great an overhead to
> > consider for such outlandish use-cases?
>
> This issue was raised some ago, for the dummy device
>
> modprobe dummy numdummies=33000
>
> I guess each format (eg eth%d) could be attached/associated to an idr,
> so that we can find the lowest available index very fast.
You could try vzalloc() instead of get_zeroed_page which would allow for
bigger bitmap.
^ permalink raw reply
* [RFC PATCH 1/2] net: Add support for hardware-offloaded encapsulation
From: Joseph Gasparakis @ 2012-10-25 18:29 UTC (permalink / raw)
To: davem, shemminger, chrisw
Cc: Joseph Gasparakis, netdev, Peter P Waskiewicz Jr
In-Reply-To: <1351189753-5912-1-git-send-email-joseph.gasparakis@intel.com>
This patch adds suport in the kernel for offloading in the NIC Tx and Rx checksuming for encapsulated packets (such as VXLAN and IP GRE)
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
Documentation/networking/netdev-features.txt | 10 +++
include/linux/if_ether.h | 5 ++
include/linux/ip.h | 5 ++
include/linux/netdev_features.h | 3 +
include/linux/skbuff.h | 114 +++++++++++++++++++++++++++
include/linux/udp.h | 5 ++
net/core/ethtool.c | 2 +
7 files changed, 144 insertions(+)
diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt
index 4164f5c..82695c0 100644
--- a/Documentation/networking/netdev-features.txt
+++ b/Documentation/networking/netdev-features.txt
@@ -165,3 +165,13 @@ This requests that the NIC receive all possible frames, including errored
frames (such as bad FCS, etc). This can be helpful when sniffing a link with
bad packets on it. Some NICs may receive more packets if also put into normal
PROMISC mdoe.
+
+* tx-enc-checksum-offload
+
+This feature implies that the NIC will be able to calculate the Tx checksums
+for both inner and outer packets in the case of vxlan and ipgre encapsulation.
+
+* rx-enc-checksum-offload
+
+This feature implies that the NIC will be able to verify the Rx checksums
+for both inner and outer packets in the case of vxlan and ipgre encapsulation.
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index 167ce5b..b6ebb4b5 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -139,6 +139,11 @@ static inline struct ethhdr *eth_hdr(const struct sk_buff *skb)
return (struct ethhdr *)skb_mac_header(skb);
}
+static inline struct ethhdr *eth_inner_hdr(const struct sk_buff *skb)
+{
+ return (struct ethhdr *)skb_inner_mac_header(skb);
+}
+
int eth_header_parse(const struct sk_buff *skb, unsigned char *haddr);
int mac_pton(const char *s, u8 *mac);
diff --git a/include/linux/ip.h b/include/linux/ip.h
index bd0a2a8..e94f000 100644
--- a/include/linux/ip.h
+++ b/include/linux/ip.h
@@ -112,6 +112,11 @@ static inline struct iphdr *ip_hdr(const struct sk_buff *skb)
return (struct iphdr *)skb_network_header(skb);
}
+static inline struct iphdr *ip_inner_hdr(const struct sk_buff *skb)
+{
+ return (struct iphdr *)skb_inner_network_header(skb);
+}
+
static inline struct iphdr *ipip_hdr(const struct sk_buff *skb)
{
return (struct iphdr *)skb_transport_header(skb);
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 5ac3212..6dd59a5 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -19,6 +19,7 @@ enum {
NETIF_F_IP_CSUM_BIT, /* Can checksum TCP/UDP over IPv4. */
__UNUSED_NETIF_F_1,
NETIF_F_HW_CSUM_BIT, /* Can checksum all the packets. */
+ NETIF_F_HW_CSUM_ENC_BIT, /* Can checksum all inner headers */
NETIF_F_IPV6_CSUM_BIT, /* Can checksum TCP/UDP over IPV6 */
NETIF_F_HIGHDMA_BIT, /* Can DMA to high memory. */
NETIF_F_FRAGLIST_BIT, /* Scatter/gather IO. */
@@ -52,6 +53,8 @@ enum {
NETIF_F_NTUPLE_BIT, /* N-tuple filters supported */
NETIF_F_RXHASH_BIT, /* Receive hashing offload */
NETIF_F_RXCSUM_BIT, /* Receive checksumming offload */
+ NETIF_F_RXCSUM_ENC_BIT, /* Receive checksuming offload */
+ /* for encapsulation */
NETIF_F_NOCACHE_COPY_BIT, /* Use no-cache copyfromuser */
NETIF_F_LOOPBACK_BIT, /* Enable loopback */
NETIF_F_RXFCS_BIT, /* Append FCS to skb pkt data */
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index b33a3a1..aaa17a8 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -377,6 +377,9 @@ typedef unsigned char *sk_buff_data_t;
* @transport_header: Transport layer header
* @network_header: Network layer header
* @mac_header: Link layer header
+ * @inner_transport_header: Inner transport layer header (encapsulation)
+ * @inner_network_header: Network layer header (encapsulation)
+ * @inner_mac_header: Link layer header (encapsulation)
* @tail: Tail pointer
* @end: End pointer
* @head: Head of buffer
@@ -487,6 +490,9 @@ struct sk_buff {
sk_buff_data_t transport_header;
sk_buff_data_t network_header;
sk_buff_data_t mac_header;
+ sk_buff_data_t inner_transport_header;
+ sk_buff_data_t inner_network_header;
+ sk_buff_data_t inner_mac_header;
/* These elements must be at the end, see alloc_skb() for details. */
sk_buff_data_t tail;
sk_buff_data_t end;
@@ -1441,6 +1447,63 @@ static inline void skb_reset_mac_len(struct sk_buff *skb)
}
#ifdef NET_SKBUFF_DATA_USES_OFFSET
+static inline unsigned char *skb_inner_transport_header(const struct sk_buff
+ *skb)
+{
+ return skb->head + skb->inner_transport_header;
+}
+
+static inline void skb_reset_inner_transport_header(struct sk_buff *skb)
+{
+ skb->inner_transport_header = skb->data - skb->head;
+}
+
+static inline void skb_set_inner_transport_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb_reset_inner_transport_header(skb);
+ skb->inner_transport_header += offset;
+}
+
+static inline unsigned char *skb_inner_network_header(const struct sk_buff *skb)
+{
+ return skb->head + skb->inner_network_header;
+}
+
+static inline void skb_reset_inner_network_header(struct sk_buff *skb)
+{
+ skb->inner_network_header = skb->data - skb->head;
+}
+
+static inline void skb_set_inner_network_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb_reset_inner_network_header(skb);
+ skb->inner_network_header += offset;
+}
+
+static inline unsigned char *skb_inner_mac_header(const struct sk_buff *skb)
+{
+ return skb->head + skb->inner_mac_header;
+}
+
+static inline int skb_inner_mac_header_was_set(const struct sk_buff *skb)
+{
+ return skb->inner_mac_header != ~0U;
+}
+
+static inline void skb_reset_inner_mac_header(struct sk_buff *skb)
+{
+ skb->inner_mac_header = skb->data - skb->head;
+}
+
+static inline void skb_set_inner_mac_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb_reset_inner_mac_header(skb);
+ skb->inner_mac_header += offset;
+}
+
static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
{
return skb->head + skb->transport_header;
@@ -1496,7 +1559,58 @@ static inline void skb_set_mac_header(struct sk_buff *skb, const int offset)
}
#else /* NET_SKBUFF_DATA_USES_OFFSET */
+static inline unsigned char *skb_inner_transport_header(const struct sk_buff
+ *skb)
+{
+ return skb->inner_transport_header;
+}
+
+static inline void skb_reset_inner_transport_header(struct sk_buff *skb)
+{
+ skb->inner_transport_header = skb->data;
+}
+
+static inline void skb_set_inner_transport_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb->inner_transport_header = skb->data + offset;
+}
+
+static inline unsigned char *skb_inner_network_header(const struct sk_buff *skb)
+{
+ return skb->inner_network_header;
+}
+
+static inline void skb_reset_inner_network_header(struct sk_buff *skb)
+{
+ skb->inner_network_header = skb->data;
+}
+
+static inline void skb_set_inner_network_header(struct sk_buff *skb,
+ const int offset)
+{
+ skb->inner_network_header = skb->data + offset;
+}
+
+static inline unsigned char *skb_inner_mac_header(const struct sk_buff *skb)
+{
+ return skb->inner_mac_header;
+}
+
+static inline int skb_inner_mac_header_was_set(const struct sk_buff *skb)
+{
+ return skb->inner_mac_header != NULL;
+}
+static inline void skb_reset_mac_header(struct sk_buff *skb)
+{
+ skb->inner_mac_header = skb->data;
+}
+
+static inline void skb_set_mac_header(struct sk_buff *skb, const int offset)
+{
+ skb->inner_mac_header = skb->data + offset;
+}
static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
{
return skb->transport_header;
diff --git a/include/linux/udp.h b/include/linux/udp.h
index 03f72a2..e3294fd 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -45,6 +45,11 @@ static inline struct udphdr *udp_hdr(const struct sk_buff *skb)
return (struct udphdr *)skb_transport_header(skb);
}
+static inline struct udphdr *udp_inner_hdr(const struct sk_buff *skb)
+{
+ return (struct udphdr *)skb_inner_transport_header(skb);
+}
+
#define UDP_HTABLE_SIZE_MIN (CONFIG_BASE_SMALL ? 128 : 256)
static inline int udp_hashfn(struct net *net, unsigned num, unsigned mask)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4d64cc2..11f928d 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -58,6 +58,7 @@ static const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN]
[NETIF_F_IP_CSUM_BIT] = "tx-checksum-ipv4",
[NETIF_F_HW_CSUM_BIT] = "tx-checksum-ip-generic",
[NETIF_F_IPV6_CSUM_BIT] = "tx-checksum-ipv6",
+ [NETIF_F_HW_CSUM_ENC_BIT] = "tx-checksum-enc-offload",
[NETIF_F_HIGHDMA_BIT] = "highdma",
[NETIF_F_FRAGLIST_BIT] = "tx-scatter-gather-fraglist",
[NETIF_F_HW_VLAN_TX_BIT] = "tx-vlan-hw-insert",
@@ -84,6 +85,7 @@ static const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN]
[NETIF_F_NTUPLE_BIT] = "rx-ntuple-filter",
[NETIF_F_RXHASH_BIT] = "rx-hashing",
[NETIF_F_RXCSUM_BIT] = "rx-checksum",
+ [NETIF_F_RXCSUM_ENC_BIT] = "rx-enc-checksum-offload",
[NETIF_F_NOCACHE_COPY_BIT] = "tx-nocache-copy",
[NETIF_F_LOOPBACK_BIT] = "loopback",
[NETIF_F_RXFCS_BIT] = "rx-fcs",
--
1.7.11.7
^ permalink raw reply related
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