* Re: [PATCH 3/4] wl1251: spi: add vio regulator support
From: Pavel Machek @ 2013-11-05 13:12 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Luciano Coelho, Rob Herring, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Rob Landley,
Tony Lindgren, Russell King, John W. Linville, Felipe Balbi,
Sachin Kamat, Greg Kroah-Hartman, Bill Pemberton,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1382890469-25286-4-git-send-email-sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
On Sun 2013-10-27 17:14:28, Sebastian Reichel wrote:
> This patch adds support for requesting the regulator powering
> the vio pin.
>
> The patch also adds the regulator for the all boards using the
> wl1251 in spi mode (only the Nokia N900).
>
> Signed-off-by: Sebastian Reichel <sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Reviewed-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Florian Westphal @ 2013-11-05 13:32 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, pablo, netfilter-devel, yoshfuji, kadlec, kaber,
mleitner, kuznet, jmorris, wensong, horms, ja, edumazet, pshelar,
jasowang, alexander.h.duyck, coreteam, fw
In-Reply-To: <1383649333-6321-3-git-send-email-jiri@resnulli.us>
Jiri Pirko <jiri@resnulli.us> wrote:
> This patch fixes for example following situation:
> On HOSTA do:
> ip6tables -I INPUT -p icmpv6 -j DROP
> ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
untested:
-A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
-A INPUT -p icmpv6 -m conntrack --ctstatus CONFIRMED -j ACCEPT
-A INPUT -p icmpv6 -j DROP
> and on HOSTB you do:
> ping6 HOSTA -s2000 (MTU is 1500)
>
> Incoming echo requests will be filtered out on HOSTA. This issue does
> not occur with smaller packets than MTU (where fragmentation does not happen).
Patrick, any reason not to kill the special-casing (ct has assigned helper or
unconfirmed conntrack) in __ipv6_conntrack_in() ?
This should make ipv6 frag behaviour consistent; right now its rather
confusing from ruleset point of view, especially the first packet
of a connection is always seen as reassembled.
So with Jiris rules
-A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
-A INPUT -p icmpv6 -j DROP
ping6 -s $bignum works for the first packet but not for subsequent ones
which is quite irritating.
This change would obviously have userspace visibility (e.g. -m frag
won't work anymore when conntrack is on), but so far I couldn't come
up with a scenario where a legitimate ruleset could break.
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Patrick McHardy @ 2013-11-05 13:41 UTC (permalink / raw)
To: Florian Westphal
Cc: Jiri Pirko, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105133205.GC15370@breakpoint.cc>
On Tue, Nov 05, 2013 at 02:32:05PM +0100, Florian Westphal wrote:
> Jiri Pirko <jiri@resnulli.us> wrote:
> > This patch fixes for example following situation:
> > On HOSTA do:
> > ip6tables -I INPUT -p icmpv6 -j DROP
> > ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>
> untested:
>
> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
> -A INPUT -p icmpv6 -m conntrack --ctstatus CONFIRMED -j ACCEPT
> -A INPUT -p icmpv6 -j DROP
>
> > and on HOSTB you do:
> > ping6 HOSTA -s2000 (MTU is 1500)
> >
> > Incoming echo requests will be filtered out on HOSTA. This issue does
> > not occur with smaller packets than MTU (where fragmentation does not happen).
>
> Patrick, any reason not to kill the special-casing (ct has assigned helper or
> unconfirmed conntrack) in __ipv6_conntrack_in() ?
>
> This should make ipv6 frag behaviour consistent; right now its rather
> confusing from ruleset point of view, especially the first packet
> of a connection is always seen as reassembled.
>
> So with Jiris rules
>
> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
> -A INPUT -p icmpv6 -j DROP
>
> ping6 -s $bignum works for the first packet but not for subsequent ones
> which is quite irritating.
Well, the reason was to avoid unnecessary work doing refragmentation
unless really required. I know its rather complicated, but IPv6 has
always required treating fragments manually or using conntrack state.
I'm not objecting to changing this, but the patches as they are are
not the way to go. First, moving nfct_frag to struct sk_buff seems
like a real waste of space for this quite rare case. Also, we can't
just use the reassembled packet in ip6tables, when modifying it we
will still output the unchanged fragments. An last of all, we'll be
executing the rules on the reassembled packet multiple times, one
for each fragment.
So if someone wants to change this, simply *only* pass the reassembled
packet through the netfilter hooks and drop the fragments, as in IPv4.
^ permalink raw reply
* [PATCH net-next 0/3] IPsec improvements
From: Mathias Krause @ 2013-11-05 13:54 UTC (permalink / raw)
To: David S. Miller, Steffen Klassert, Herbert Xu
Cc: Dmitry Tarnyagin, netdev, Mathias Krause
This series moves pskb_put() to the core code -- making the code
duplication in caif obsolete (patches 1 and 2).
Additionally does this series optimize the IPsec receive path in patch 3
by allowing skb_cow_data() to leave the buffer fragmented. I noticed the
linearization to be a bottleneck when doing some VPN gateway benchmarks.
Linearization of the buffer isn't needed in the receive path as the
crypto API (and all other users of skb_cow_data) can handle sg.
With patch 3 applied I was able to increase the throughput of an IPsec
gateway from 7.12 Gbit/s to 7.28 Gbit/s.
Please apply!
Mathias Krause (3):
net: move pskb_put() to core code
caif: use pskb_put() instead of reimplementing its functionality
net: allow to leave the buffer fragmented in skb_cow_data()
include/linux/skbuff.h | 1 +
include/net/esp.h | 2 -
net/caif/cfpkt_skbuff.c | 12 +----------
net/core/skbuff.c | 52 +++++++++++++++++++++++++++++++++++++----------
net/xfrm/xfrm_algo.c | 13 -----------
5 files changed, 43 insertions(+), 37 deletions(-)
--
1.7.2.5
^ permalink raw reply
* [PATCH net-next 2/3] caif: use pskb_put() instead of reimplementing its functionality
From: Mathias Krause @ 2013-11-05 13:54 UTC (permalink / raw)
To: David S. Miller, Steffen Klassert, Herbert Xu
Cc: Dmitry Tarnyagin, netdev, Mathias Krause, David S. Miller
In-Reply-To: <cover.1381923854.git.mathias.krause@secunet.com>
Also remove the warning for fragmented packets -- skb_cow_data() will
linearize the buffer, removing all fragments.
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
Cc: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
Cc: "David S. Miller" <davem@davemloft.net>
---
net/caif/cfpkt_skbuff.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/net/caif/cfpkt_skbuff.c b/net/caif/cfpkt_skbuff.c
index 6493351..1be0b52 100644
--- a/net/caif/cfpkt_skbuff.c
+++ b/net/caif/cfpkt_skbuff.c
@@ -203,20 +203,10 @@ int cfpkt_add_body(struct cfpkt *pkt, const void *data, u16 len)
PKT_ERROR(pkt, "cow failed\n");
return -EPROTO;
}
- /*
- * Is the SKB non-linear after skb_cow_data()? If so, we are
- * going to add data to the last SKB, so we need to adjust
- * lengths of the top SKB.
- */
- if (lastskb != skb) {
- pr_warn("Packet is non-linear\n");
- skb->len += len;
- skb->data_len += len;
- }
}
/* All set to put the last SKB and optionally write data there. */
- to = skb_put(lastskb, len);
+ to = pskb_put(skb, lastskb, len);
if (likely(data))
memcpy(to, data, len);
return 0;
--
1.7.2.5
^ permalink raw reply related
* [PATCH net-next 1/3] net: move pskb_put() to core code
From: Mathias Krause @ 2013-11-05 13:54 UTC (permalink / raw)
To: David S. Miller, Steffen Klassert, Herbert Xu
Cc: Dmitry Tarnyagin, netdev, Mathias Krause, Steffen Klassert,
David S. Miller, Herbert Xu
In-Reply-To: <cover.1381923854.git.mathias.krause@secunet.com>
This function has usage beside IPsec so move it to the core skbuff code.
While doing so, give it some documentation and change its return type to
'unsigned char *' to be in line with skb_put().
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
include/linux/skbuff.h | 1 +
include/net/esp.h | 2 --
net/core/skbuff.c | 23 +++++++++++++++++++++++
net/xfrm/xfrm_algo.c | 13 -------------
4 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c2d8933..9d785f4d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1418,6 +1418,7 @@ static inline void skb_set_tail_pointer(struct sk_buff *skb, const int offset)
/*
* Add data to an sk_buff
*/
+unsigned char *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len);
unsigned char *skb_put(struct sk_buff *skb, unsigned int len);
static inline unsigned char *__skb_put(struct sk_buff *skb, unsigned int len)
{
diff --git a/include/net/esp.h b/include/net/esp.h
index d584513..5b4fdcc 100644
--- a/include/net/esp.h
+++ b/include/net/esp.h
@@ -13,8 +13,6 @@ struct esp_data {
#include <linux/skbuff.h>
-void *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len);
-
struct ip_esp_hdr;
static inline struct ip_esp_hdr *ip_esp_hdr(const struct sk_buff *skb)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d81cff1..247023d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1257,6 +1257,29 @@ free_skb:
EXPORT_SYMBOL(skb_pad);
/**
+ * pskb_put - add data to the tail of a potentially fragmented buffer
+ * @skb: start of the buffer to use
+ * @tail: tail fragment of the buffer to use
+ * @len: amount of data to add
+ *
+ * This function extends the used data area of the potentially
+ * fragmented buffer. &tail must be the last fragment of &skb -- or
+ * &skb itself. If this would exceed the total buffer size the kernel
+ * will panic. A pointer to the first byte of the extra data is
+ * returned.
+ */
+
+unsigned char *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len)
+{
+ if (tail != skb) {
+ skb->data_len += len;
+ skb->len += len;
+ }
+ return skb_put(tail, len);
+}
+EXPORT_SYMBOL_GPL(pskb_put);
+
+/**
* skb_put - add data to a buffer
* @skb: buffer to use
* @len: amount of data to add
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index ab4ef72..debe733 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -802,17 +802,4 @@ int xfrm_count_pfkey_enc_supported(void)
}
EXPORT_SYMBOL_GPL(xfrm_count_pfkey_enc_supported);
-#if defined(CONFIG_INET_ESP) || defined(CONFIG_INET_ESP_MODULE) || defined(CONFIG_INET6_ESP) || defined(CONFIG_INET6_ESP_MODULE)
-
-void *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len)
-{
- if (tail != skb) {
- skb->data_len += len;
- skb->len += len;
- }
- return skb_put(tail, len);
-}
-EXPORT_SYMBOL_GPL(pskb_put);
-#endif
-
MODULE_LICENSE("GPL");
--
1.7.2.5
^ permalink raw reply related
* [PATCH net-next 3/3] net: allow to leave the buffer fragmented in skb_cow_data()
From: Mathias Krause @ 2013-11-05 13:54 UTC (permalink / raw)
To: David S. Miller, Steffen Klassert, Herbert Xu
Cc: Dmitry Tarnyagin, netdev, Mathias Krause, David S. Miller,
Herbert Xu
In-Reply-To: <cover.1381923854.git.mathias.krause@secunet.com>
Do not linearize the buffer per se but only if we're expected to expand
the tail. All callers can handle fragmented buffers and even expect
them!
Not linearizing the buffer leads to a small performance improvement for
the IPsec receive path in case the network driver passed us a fragmented
buffer.
With this patch applied I was able to increase the throughput of an
IPsec gateway from 7.12 Gbit/s to 7.28 Gbit/s.
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
net/core/skbuff.c | 29 ++++++++++++++++++-----------
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 247023d..5eec1b9 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3207,7 +3207,7 @@ EXPORT_SYMBOL_GPL(skb_to_sgvec);
*
* If @tailbits is given, make sure that there is space to write @tailbits
* bytes of data beyond current end of socket buffer. @trailer will be
- * set to point to the skb in which this space begins.
+ * linearized and set to point to the skb in which this space begins.
*
* The number of scatterlist elements required to completely map the
* COW'd and extended socket buffer will be returned.
@@ -3218,11 +3218,10 @@ int skb_cow_data(struct sk_buff *skb, int tailbits, struct sk_buff **trailer)
int elt;
struct sk_buff *skb1, **skb_p;
- /* If skb is cloned or its head is paged, reallocate
- * head pulling out all the pages (pages are considered not writable
- * at the moment even if they are anonymous).
+ /* If skb is cloned reallocate head pulling out all the pages (pages are
+ * considered not writable at the moment even if they are anonymous).
*/
- if ((skb_cloned(skb) || skb_shinfo(skb)->nr_frags) &&
+ if (skb_cloned(skb) &&
__pskb_pull_tail(skb, skb_pagelen(skb)-skb_headlen(skb)) == NULL)
return -ENOMEM;
@@ -3233,18 +3232,26 @@ int skb_cow_data(struct sk_buff *skb, int tailbits, struct sk_buff **trailer)
* good frames. OK, on miss we reallocate and reserve even more
* space, 128 bytes is fair. */
- if (skb_tailroom(skb) < tailbits &&
- pskb_expand_head(skb, 0, tailbits-skb_tailroom(skb)+128, GFP_ATOMIC))
- return -ENOMEM;
+ if (tailbits) {
+ if (skb_linearize(skb))
+ return -ENOMEM;
+
+ if (skb_tailroom(skb) < tailbits) {
+ int ntail = tailbits - skb_tailroom(skb) + 128;
+
+ if (pskb_expand_head(skb, 0, ntail, GFP_ATOMIC))
+ return -ENOMEM;
+ }
+ }
/* Voila! */
*trailer = skb;
- return 1;
+ return skb_shinfo(skb)->nr_frags + 1;
}
/* Misery. We are in troubles, going to mincer fragments... */
- elt = 1;
+ elt = skb_shinfo(skb)->nr_frags + 1;
skb_p = &skb_shinfo(skb)->frag_list;
copyflag = 0;
@@ -3296,7 +3303,7 @@ int skb_cow_data(struct sk_buff *skb, int tailbits, struct sk_buff **trailer)
kfree_skb(skb1);
skb1 = skb2;
}
- elt++;
+ elt += skb_shinfo(skb1)->nr_frags + 1;
*trailer = skb1;
skb_p = &skb1->next;
}
--
1.7.2.5
^ permalink raw reply related
* Re: [patch net-next 3/3] fix skb_morph to preserve skb->sk and skb->destructor pointers
From: Eric Dumazet @ 2013-11-05 14:06 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, pablo, netfilter-devel, yoshfuji, kadlec, kaber,
mleitner, kuznet, jmorris, wensong, horms, ja, edumazet, pshelar,
jasowang, alexander.h.duyck, coreteam, fw
In-Reply-To: <1383649333-6321-4-git-send-email-jiri@resnulli.us>
On Tue, 2013-11-05 at 12:02 +0100, Jiri Pirko wrote:
> Currently __skb_clone sets skb->sk and skb->destructor to NULL. This is
> not right for skb_morph use case because skb->sk may be previously
> set (e. g. by xt_TPROXY).
>
> Also, during skb_morph the destructor should not be called. It might be
> previously set, e. g. by xt_TPROXY to sock_edemux, and that would cause
> put sk while skb is still in flight.
truesize alert. You should add some documentation that skb_morph()
must not be used in transmit path.
Its not clear to be how this can happen.
skb_morph() being used only from ipv4 defrag (or ipv6 reassembly).
Maybe the problem could be fixed by doing this defrag _before_ setting
skb->sk ?
Also, I would prefer you find a way to put all this logic inside
skb_morph() instead of adding such complexity in this already complex
code, I fear the compiler will generate slower code with your patch on
fast path.
Maybe something as simple as following (untested) patch ?
Note that the truesize concern might need some care.
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 3735fad5616e..afabfd6ef341 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -793,18 +793,28 @@ static struct sk_buff *__skb_clone(struct sk_buff *n, struct sk_buff *skb)
/**
* skb_morph - morph one skb into another
- * @dst: the skb to receive the contents
+ * @skb: the skb to receive the contents
* @src: the skb to supply the contents
*
* This is identical to skb_clone except that the target skb is
- * supplied by the user.
+ * supplied by the user, and that we keep target skb destructor in place,
+ * meaning this can not be used in transmit path, as skb->truesize might
+ * change.
*
* The target skb is returned upon exit.
*/
-struct sk_buff *skb_morph(struct sk_buff *dst, struct sk_buff *src)
+struct sk_buff *skb_morph(struct sk_buff *skb, struct sk_buff *src)
{
- skb_release_all(dst);
- return __skb_clone(dst, src);
+ struct sock *save_sk = skb->sk;
+ void (*save_destructor)(struct sk_buff *) = skb->destructor;
+
+ skb->sk = NULL;
+ skb->destructor = NULL;
+ skb_release_all(skb);
+ __skb_clone(skb, src);
+ skb->sk = save_sk;
+ skb->destructor = save_destructor;
+ return skb;
}
EXPORT_SYMBOL_GPL(skb_morph);
^ permalink raw reply related
* [PATCH net] qeth: avoid buffer overflow in snmp ioctl
From: Frank Blaschka @ 2013-11-05 14:14 UTC (permalink / raw)
To: davem; +Cc: netdev, stable
From: Ursula Braun <ursula.braun@de.ibm.com>
Check user-defined length in snmp ioctl request and allow request
only if it fits into a qeth command buffer.
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Reviewed-by: Heiko Carstens <heicars2@linux.vnet.ibm.com>
Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>
Cc: <stable@vger.kernel.org>
---
drivers/s390/net/qeth_core_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index d7b66a2..642f623 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -4451,7 +4451,7 @@ int qeth_snmp_command(struct qeth_card *card, char __user *udata)
struct qeth_cmd_buffer *iob;
struct qeth_ipa_cmd *cmd;
struct qeth_snmp_ureq *ureq;
- int req_len;
+ unsigned int req_len;
struct qeth_arp_query_info qinfo = {0, };
int rc = 0;
@@ -4467,6 +4467,10 @@ int qeth_snmp_command(struct qeth_card *card, char __user *udata)
/* skip 4 bytes (data_len struct member) to get req_len */
if (copy_from_user(&req_len, udata + sizeof(int), sizeof(int)))
return -EFAULT;
+ if (req_len > QETH_BUFSIZE - IPA_PDU_HEADER_SIZE
+ - sizeof(struct qeth_ipacmd_hdr)
+ - sizeof(struct qeth_ipacmd_setadpparms_hdr))
+ return -EINVAL;
ureq = memdup_user(udata, req_len + sizeof(struct qeth_snmp_ureq_hdr));
if (IS_ERR(ureq)) {
QETH_CARD_TEXT(card, 2, "snmpnome");
^ permalink raw reply related
* Re: [PATCH 02/10] netfilter: nf_log: prepar net namespace support for nf_log
From: Arnaldo Carvalho de Melo @ 2013-11-05 14:14 UTC (permalink / raw)
To: Gao feng
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
lve-ke3WRBg/xIg, netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, pablo-Cap9r6Oaw4JrovVCs/uTlw
In-Reply-To: <1360223390-15589-2-git-send-email-gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Em Thu, Feb 07, 2013 at 03:49:42PM +0800, Gao feng escreveu:
> index 9e31269..b1e5126 100644
> +++ b/net/netfilter/nf_log.c
> @@ -16,7 +16,6 @@
> #define NF_LOG_PREFIXLEN 128
> #define NFLOGGER_NAME_LEN 64
>
> -static const struct nf_logger __rcu *nf_loggers[NFPROTO_NUMPROTO] __read_mostly;
This was initialized to zeros, but then got moved to struct netns_nf,
I'm trying to figure it out if it is being zeroed somewhere, ideas?
- Arnaldo
^ permalink raw reply
* Re: [PATCH v2 1/2] net: Add layer 2 hardware acceleration operations for macvlan devices
From: Neil Horman @ 2013-11-05 14:15 UTC (permalink / raw)
To: John Fastabend; +Cc: alexander.h.duyck, netdev, andy, davem, jeffrey.t.kirsher
In-Reply-To: <20131104190149.11802.34110.stgit@jf-dev1-dcblab>
On Mon, Nov 04, 2013 at 11:01:49AM -0800, John Fastabend wrote:
> Add a operations structure that allows a network interface to export
> the fact that it supports package forwarding in hardware between
> physical interfaces and other mac layer devices assigned to it (such
> as macvlans). This operaions structure can be used by virtual mac
> devices to bypass software switching so that forwarding can be done
> in hardware more efficiently.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: "David S. Miller" <davem@davemloft.net>
For when you send your V3 patch set out:
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] ixgbe: enable l2 forwarding acceleration for macvlans
From: Neil Horman @ 2013-11-05 14:26 UTC (permalink / raw)
To: John Fastabend; +Cc: alexander.h.duyck, netdev, andy, davem, jeffrey.t.kirsher
In-Reply-To: <20131104190154.11802.75724.stgit@jf-dev1-dcblab>
On Mon, Nov 04, 2013 at 11:01:55AM -0800, John Fastabend wrote:
> Now that l2 acceleration ops are in place from the prior patch,
> enable ixgbe to take advantage of these operations. Allow it to
> allocate queues for a macvlan so that when we transmit a frame,
> we can do the switching in hardware inside the ixgbe card, rather
> than in software.
>
> For now this patch limits the hardware to 8 offloaded macvlan ports.
> A follow on patch will remove this limitation but to simplify
> review/validation of the new macvlan offload ops we leave it at 8
> for now.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: "David S. Miller" <davem@davemloft.net>
A few Nits, since you're going to send a V3 anyway. Comments inline.
> ---
><snip>
> +static void ixgbe_configure_vsi(struct ixgbe_adapter *adapter)
> +{
> + struct net_device *upper;
> + struct list_head *iter;
> + int err;
> +
> + netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
> + if (netif_is_macvlan(upper)) {
> + struct macvlan_dev *vlan = netdev_priv(upper);
> + struct ixgbe_fwd_adapter *vadapter = vlan->fwd_priv;
> +
> + if (vlan->fwd_priv) {
> + err = ixgbe_fwd_ring_up(upper, vadapter);
> + if (err)
> + continue;
> + ixgbe_macvlan_set_rx_mode(upper,
> + vadapter->pool,
> + adapter);
Nit: You're using macvlan here, and vsi above. Might be nice to give everything
a consistent suffix/prefix for clarity. Perhaps dfwd since thats what the new
ndo_ops uses?
><snip>
> static inline bool ixgbe_is_sfp(struct ixgbe_hw *hw)
> @@ -4317,6 +4521,8 @@ static void ixgbe_setup_gpie(struct ixgbe_adapter *adapter)
> static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
> {
> struct ixgbe_hw *hw = &adapter->hw;
> + struct net_device *upper;
> + struct list_head *iter;
> int err;
> u32 ctrl_ext;
>
> @@ -4360,6 +4566,16 @@ static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
> /* enable transmits */
> netif_tx_start_all_queues(adapter->netdev);
>
> + /* enable any upper devices */
> + netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
> + if (netif_is_macvlan(upper)) {
> + struct macvlan_dev *vlan = netdev_priv(upper);
> +
> + if (vlan->fwd_priv)
> + netif_tx_start_all_queues(upper);
> + }
> + }
> +
I don't think it matters much, but do we want to start the upper devs queues
here unilaterally? Nominally a network interface starts its queues on dev_open.
Would it be better to only start those devices if (vlan->fwd_priv &&
(upper->flags & IFF_UP)? We would then have to listen for NETDEV_UP events as
well to handle accelerated macvlans comming up after ixgbe does, which is more
work, but I wanted to mention this in case theres some disadvantage to starting
the queue early.
Other than that I think it looks good though. Nice work!
Regards
Neil
^ permalink raw reply
* [PATCH net-next v3 1/4] ipv6: remove old conditions on flow label sharing
From: Florent Fourcot @ 2013-11-05 14:28 UTC (permalink / raw)
To: netdev; +Cc: Florent Fourcot
The code of flow label in Linux Kernel follows
the rules of RFC 1809 (an informational one) for
conditions on flow label sharing. There rules are
not in the last proposed standard for flow label
(RFC 6437), or in the previous one (RFC 3697).
Since this code does not follow any current or
old standard, we can remove it.
With this removal, the ipv6_opt_cmp and
pv6_hdr_cmp function are now a dead code and it
can be removed too.
Changelog of v2:
* add justification for the change
* remove the condition on IPv6 options
* remove ipv6_opt_cmp
v3:
* remove ipv6_hdr_cmp
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
net/ipv6/ip6_flowlabel.c | 33 ---------------------------------
1 file changed, 33 deletions(-)
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 46e8843..819578e 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -465,34 +465,6 @@ static int mem_check(struct sock *sk)
return 0;
}
-static bool ipv6_hdr_cmp(struct ipv6_opt_hdr *h1, struct ipv6_opt_hdr *h2)
-{
- if (h1 == h2)
- return false;
- if (h1 == NULL || h2 == NULL)
- return true;
- if (h1->hdrlen != h2->hdrlen)
- return true;
- return memcmp(h1+1, h2+1, ((h1->hdrlen+1)<<3) - sizeof(*h1));
-}
-
-static bool ipv6_opt_cmp(struct ipv6_txoptions *o1, struct ipv6_txoptions *o2)
-{
- if (o1 == o2)
- return false;
- if (o1 == NULL || o2 == NULL)
- return true;
- if (o1->opt_nflen != o2->opt_nflen)
- return true;
- if (ipv6_hdr_cmp(o1->hopopt, o2->hopopt))
- return true;
- if (ipv6_hdr_cmp(o1->dst0opt, o2->dst0opt))
- return true;
- if (ipv6_hdr_cmp((struct ipv6_opt_hdr *)o1->srcrt, (struct ipv6_opt_hdr *)o2->srcrt))
- return true;
- return false;
-}
-
static inline void fl_link(struct ipv6_pinfo *np, struct ipv6_fl_socklist *sfl,
struct ip6_flowlabel *fl)
{
@@ -603,11 +575,6 @@ recheck:
uid_eq(fl1->owner.uid, fl->owner.uid)))
goto release;
- err = -EINVAL;
- if (!ipv6_addr_equal(&fl1->dst, &fl->dst) ||
- ipv6_opt_cmp(fl1->opt, fl->opt))
- goto release;
-
err = -ENOMEM;
if (sfl1 == NULL)
goto release;
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH net-next 3/4] ipv6: increase maximum lifetime of flow labels
From: Florent Fourcot @ 2013-11-05 14:28 UTC (permalink / raw)
To: netdev; +Cc: Florent Fourcot
In-Reply-To: <1383661738-6083-1-git-send-email-florent.fourcot@enst-bretagne.fr>
If the last RFC 6437 does not give any constraints
for lifetime of flow labels, the previous RFC 3697
spoke of a minimum of 120 seconds quarantine
for a flow label.
The maximum linger is currently set to 60 seconds
and does not allow this configuration without
CAP_NET_ADMIN right.
This patch increases the maximum linger to 150
seconds, allowing more flexibility to standard
users.
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
net/ipv6/ip6_flowlabel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 76e62a1..41ced9c 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -41,7 +41,7 @@
#define FL_MIN_LINGER 6 /* Minimal linger. It is set to 6sec specified
in old IPv6 RFC. Well, it was reasonable value.
*/
-#define FL_MAX_LINGER 60 /* Maximal linger timeout */
+#define FL_MAX_LINGER 150 /* Maximal linger timeout */
/* FL hash table */
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH net-next v2 2/4] ipv6: enable IPV6_FLOWLABEL_MGR for getsockopt
From: Florent Fourcot @ 2013-11-05 14:28 UTC (permalink / raw)
To: netdev; +Cc: Florent Fourcot
In-Reply-To: <1383661738-6083-1-git-send-email-florent.fourcot@enst-bretagne.fr>
It is already possible to set/put/renew a label
with IPV6_FLOWLABEL_MGR and setsockopt. This patch
add the possibility to get information about this
label (current value, time before expiration, etc).
It helps application to take decision for a renew
or a release of the label.
v2:
* Add spin_lock to prevent race condition
* return -ENOENT if no result found
* check if flr_action is GET
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
include/net/ipv6.h | 1 +
net/ipv6/ip6_flowlabel.c | 27 +++++++++++++++++++++++++++
net/ipv6/ipv6_sockglue.c | 28 ++++++++++++++++++++++++++++
3 files changed, 56 insertions(+)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index dd96638..2a5f668 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -250,6 +250,7 @@ struct ipv6_txoptions *fl6_merge_options(struct ipv6_txoptions *opt_space,
struct ipv6_txoptions *fopt);
void fl6_free_socklist(struct sock *sk);
int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen);
+int ipv6_flowlabel_opt_get(struct sock *sk, struct in6_flowlabel_req *freq);
int ip6_flowlabel_init(void);
void ip6_flowlabel_cleanup(void);
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 819578e..76e62a1 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -475,6 +475,33 @@ static inline void fl_link(struct ipv6_pinfo *np, struct ipv6_fl_socklist *sfl,
spin_unlock_bh(&ip6_sk_fl_lock);
}
+int ipv6_flowlabel_opt_get(struct sock *sk, struct in6_flowlabel_req *freq)
+{
+ struct ipv6_pinfo *np = inet6_sk(sk);
+ struct ipv6_fl_socklist *sfl;
+
+ spin_lock_bh(&ip6_fl_lock);
+ rcu_read_lock_bh();
+
+ for_each_sk_fl_rcu(np, sfl) {
+ if (sfl->fl->label == (np->flow_label & IPV6_FLOWLABEL_MASK)) {
+ freq->flr_label = sfl->fl->label;
+ freq->flr_dst = sfl->fl->dst;
+ freq->flr_share = sfl->fl->share;
+ freq->flr_expires = (sfl->fl->expires - jiffies) / HZ;
+ freq->flr_linger = sfl->fl->linger / HZ;
+
+ rcu_read_unlock_bh();
+ spin_unlock_bh(&ip6_fl_lock);
+ return 0;
+ }
+ }
+ rcu_read_unlock_bh();
+ spin_unlock_bh(&ip6_fl_lock);
+
+ return -ENOENT;
+}
+
int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
{
int uninitialized_var(err);
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 4919a8e..1c6ce31 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1212,6 +1212,34 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
val = np->sndflow;
break;
+ case IPV6_FLOWLABEL_MGR:
+ {
+ struct in6_flowlabel_req freq;
+
+ if (len < sizeof(freq))
+ return -EINVAL;
+
+ if (copy_from_user(&freq, optval, sizeof(freq)))
+ return -EFAULT;
+
+ if (freq.flr_action != IPV6_FL_A_GET)
+ return -EINVAL;
+
+ len = sizeof(freq);
+ memset(&freq, 0, sizeof(freq));
+
+ val = ipv6_flowlabel_opt_get(sk, &freq);
+ if (val < 0)
+ return val;
+
+ if (put_user(len, optlen))
+ return -EFAULT;
+ if (copy_to_user(optval, &freq, len))
+ return -EFAULT;
+
+ return 0;
+ }
+
case IPV6_ADDR_PREFERENCES:
val = 0;
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH net-next 4/4] ipv6: protect flow label renew against GC
From: Florent Fourcot @ 2013-11-05 14:28 UTC (permalink / raw)
To: netdev; +Cc: Florent Fourcot
In-Reply-To: <1383661738-6083-1-git-send-email-florent.fourcot@enst-bretagne.fr>
Take ip6_fl_lock before to read and update a
label. It prevents race condition if GC is
running.
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
net/ipv6/ip6_flowlabel.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 41ced9c..1d2fc48 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -540,11 +540,13 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
return -ESRCH;
case IPV6_FL_A_RENEW:
+ spin_lock_bh(&ip6_fl_lock);
rcu_read_lock_bh();
for_each_sk_fl_rcu(np, sfl) {
if (sfl->fl->label == freq.flr_label) {
err = fl6_renew(sfl->fl, freq.flr_linger, freq.flr_expires);
rcu_read_unlock_bh();
+ spin_unlock_bh(&ip6_fl_lock);
return err;
}
}
@@ -555,10 +557,12 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
fl = fl_lookup(net, freq.flr_label);
if (fl) {
err = fl6_renew(fl, freq.flr_linger, freq.flr_expires);
+ spin_unlock_bh(&ip6_fl_lock);
fl_release(fl);
return err;
}
}
+ spin_unlock_bh(&ip6_fl_lock);
return -ESRCH;
case IPV6_FL_A_GET:
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH net] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: Christophe Gouault @ 2013-11-05 14:31 UTC (permalink / raw)
To: Sergei Shtylyov, Steffen Klassert, David S. Miller
Cc: Herbert Xu, Saurabh Mohan, netdev
In-Reply-To: <5278ED2C.8070604@cogentembedded.com>
Hello Sergei,
On 11/05/2013 02:05 PM, Sergei Shtylyov wrote:
>> diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
>> index 6e87f85..a7e03c0 100644
>> --- a/net/ipv4/ip_vti.c
>> +++ b/net/ipv4/ip_vti.c
> [...]
>> @@ -133,7 +134,12 @@ static int vti_rcv(struct sk_buff *skb)
>> * only match policies with this mark.
>> */
>> skb->mark = be32_to_cpu(tunnel->parms.o_key);
>> + /* the packet is decrypted, but not yet decapsulated.
>> + * Temporarily make network_header point to the inner header
>> + * for policy check */
>
> Multi-line comment style in the networking code is:
>
> /* bla
> * bla
> */
Sorry for that, I was not careful enough. I'll fix it right now.
Thanks and Best Regards,
Christophe
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: allow to leave the buffer fragmented in skb_cow_data()
From: Eric Dumazet @ 2013-11-05 14:33 UTC (permalink / raw)
To: Mathias Krause
Cc: David S. Miller, Steffen Klassert, Herbert Xu, Dmitry Tarnyagin,
netdev
In-Reply-To: <14f30e8f5f8405c1ca73b6d3a554441c1736142d.1381923854.git.mathias.krause@secunet.com>
On Tue, 2013-11-05 at 14:54 +0100, Mathias Krause wrote:
> Do not linearize the buffer per se but only if we're expected to expand
> the tail. All callers can handle fragmented buffers and even expect
> them!
>
> Not linearizing the buffer leads to a small performance improvement for
> the IPsec receive path in case the network driver passed us a fragmented
> buffer.
>
> With this patch applied I was able to increase the throughput of an
> IPsec gateway from 7.12 Gbit/s to 7.28 Gbit/s.
What is the driver you used ?
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: allow to leave the buffer fragmented in skb_cow_data()
From: Mathias Krause @ 2013-11-05 14:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Steffen Klassert, Herbert Xu, Dmitry Tarnyagin,
netdev
In-Reply-To: <1383661995.4291.137.camel@edumazet-glaptop2.roam.corp.google.com>
On 05.11.2013 15:33, Eric Dumazet wrote:
> On Tue, 2013-11-05 at 14:54 +0100, Mathias Krause wrote:
>> Do not linearize the buffer per se but only if we're expected to expand
>> the tail. All callers can handle fragmented buffers and even expect
>> them!
>>
>> Not linearizing the buffer leads to a small performance improvement for
>> the IPsec receive path in case the network driver passed us a fragmented
>> buffer.
>>
>> With this patch applied I was able to increase the throughput of an
>> IPsec gateway from 7.12 Gbit/s to 7.28 Gbit/s.
>
> What is the driver you used ?
The device driver is ixgbe driving an Intel X520-T2. Why you're asking?
^ permalink raw reply
* Re: [PATCH v2 0/2] l2 hardware accelerated macvlans
From: Vlad Yasevich @ 2013-11-05 14:47 UTC (permalink / raw)
To: John Fastabend, nhorman, alexander.h.duyck
Cc: netdev, andy, davem, jeffrey.t.kirsher
In-Reply-To: <20131104185717.11802.69282.stgit@jf-dev1-dcblab>
Hi John
On 11/04/2013 02:01 PM, John Fastabend wrote:
> This patch adds support to offload macvlan net_devices to the
> hardware. With these patches packets are pushed to the macvlan
> net_device directly and do not pass through the lower dev.
>
> The patches here have made it through multiple iterations
> each with a slightly different focus. First I tried to
> push these as a new link type called "VMDQ". The patches
> shown here,
>
> http://comments.gmane.org/gmane.linux.network/237617
>
> Following this implementation I renamed the link type
> "VSI" and addressed various comments. Finally Neil
> Horman picked up the patches and integrated the offload
> into the macvlan code. Here,
>
> http://permalink.gmane.org/gmane.linux.network/285658
>
> The attached series is clean-up of his patches, with a
> few fixes. I suspect Neil will add his signed-off-by
> line assuming I didn't mangle anything.
>
> If folks find this series acceptable there are a few
> items we can work on next. First broadcast and multicast
> will use the hardware even for local traffic with this
> series. It would be best (I think) to use the software
> path for macvlan to macvlan traffic and save the PCIe
> bus. Also this only allows for layer 2 mac forwarding
> where some hardware supports more interesting forwarding
> capabilities. Integrating with OVS may be useful here.
This seems to be saying that for macvlan-macvlan
case, you still prefere to do software based forwarding, but
patch 1 in the series seem to always attempt to do hardware
offloaded forwarding regardless of traffic and macvlan type.
Can you clarify.
Thanks
-vlad
>
> As always any comments/feedback welcome.
>
> I'm going to continue testing these on top of ixgbe but
> I believe these are stable and wanted to get them out to
> a wider audience. I've tested multiple offloaded macvlans
> with iperf and netperf using multiple sessions of each
> and seen no issues.
>
> My basic I/O test is here but I've also done some link
> testing and others,
>
> #ip link add link eth2 numtxqueues 4 numrxqueues 4 txqueuelen 50 type macvlan
> #tc qdisc add dev macvlan0 mq
> #iperf -c 10.0.0.1 -P 8 -t 5000 -i 10
>
> Changelog:
> v2: two fixes to ixgbe when all features DCB, FCoE, SR-IOV
> are enabled with macvlans. A VMDQ_P() reference
> should have been accel->pool and do not set the offset
> of the ring index from dfwd add call. The offset is used
> by SR-IOV so clearing it can cause SR-IOV quue index's
> to go sideways. With these fixes testing macvlan's with
> SRIOV enabled was successful.
>
> Thanks,
> John
>
> ---
>
> John Fastabend (2):
> ixgbe: enable l2 forwarding acceleration for macvlans
> net: Add layer 2 hardware acceleration operations for macvlan devices
>
>
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 20 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 12 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 463 +++++++++++++++++++++----
> drivers/net/macvlan.c | 36 ++
> include/linux/if_macvlan.h | 1
> include/linux/netdev_features.h | 2
> include/linux/netdevice.h | 36 ++
> include/uapi/linux/if.h | 1
> net/core/dev.c | 18 +
> net/core/ethtool.c | 1
> net/sched/sch_generic.c | 2
> 11 files changed, 504 insertions(+), 88 deletions(-)
>
^ permalink raw reply
* Re: [patch net-next 3/3] fix skb_morph to preserve skb->sk and skb->destructor pointers
From: Jiri Pirko @ 2013-11-05 14:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, pablo, netfilter-devel, yoshfuji, kadlec, kaber,
mleitner, kuznet, jmorris, wensong, horms, ja, edumazet, pshelar,
jasowang, alexander.h.duyck, coreteam, fw
In-Reply-To: <1383660372.4291.134.camel@edumazet-glaptop2.roam.corp.google.com>
Tue, Nov 05, 2013 at 03:06:12PM CET, eric.dumazet@gmail.com wrote:
>On Tue, 2013-11-05 at 12:02 +0100, Jiri Pirko wrote:
>> Currently __skb_clone sets skb->sk and skb->destructor to NULL. This is
>> not right for skb_morph use case because skb->sk may be previously
>> set (e. g. by xt_TPROXY).
>>
>> Also, during skb_morph the destructor should not be called. It might be
>> previously set, e. g. by xt_TPROXY to sock_edemux, and that would cause
>> put sk while skb is still in flight.
>
>truesize alert. You should add some documentation that skb_morph()
>must not be used in transmit path.
>
>Its not clear to be how this can happen.
>
>skb_morph() being used only from ipv4 defrag (or ipv6 reassembly).
nod
>
>Maybe the problem could be fixed by doing this defrag _before_ setting
>skb->sk ?
skb->sk is set for exmaple in xt_TPROXY that is before reassemly is
done, because reassembly is done after all the netfilter code pass the
skb through. I do not see how this can be changed in the way you are
suggesting.
>
>Also, I would prefer you find a way to put all this logic inside
>skb_morph() instead of adding such complexity in this already complex
>code, I fear the compiler will generate slower code with your patch on
>fast path.
>
>Maybe something as simple as following (untested) patch ?
I had very similar patch prepared. But I did not like it so I chose the
other way. I'm more or less okay with doing this this way though...
>
>Note that the truesize concern might need some care.
>
>diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>index 3735fad5616e..afabfd6ef341 100644
>--- a/net/core/skbuff.c
>+++ b/net/core/skbuff.c
>@@ -793,18 +793,28 @@ static struct sk_buff *__skb_clone(struct sk_buff *n, struct sk_buff *skb)
>
> /**
> * skb_morph - morph one skb into another
>- * @dst: the skb to receive the contents
>+ * @skb: the skb to receive the contents
> * @src: the skb to supply the contents
> *
> * This is identical to skb_clone except that the target skb is
>- * supplied by the user.
>+ * supplied by the user, and that we keep target skb destructor in place,
>+ * meaning this can not be used in transmit path, as skb->truesize might
>+ * change.
> *
> * The target skb is returned upon exit.
> */
>-struct sk_buff *skb_morph(struct sk_buff *dst, struct sk_buff *src)
>+struct sk_buff *skb_morph(struct sk_buff *skb, struct sk_buff *src)
> {
>- skb_release_all(dst);
>- return __skb_clone(dst, src);
>+ struct sock *save_sk = skb->sk;
>+ void (*save_destructor)(struct sk_buff *) = skb->destructor;
>+
>+ skb->sk = NULL;
>+ skb->destructor = NULL;
>+ skb_release_all(skb);
>+ __skb_clone(skb, src);
>+ skb->sk = save_sk;
>+ skb->destructor = save_destructor;
>+ return skb;
> }
> EXPORT_SYMBOL_GPL(skb_morph);
>
>
>
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Jiri Pirko @ 2013-11-05 15:01 UTC (permalink / raw)
To: Patrick McHardy
Cc: Florian Westphal, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105134118.GA5818@macbook.localnet>
Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
>On Tue, Nov 05, 2013 at 02:32:05PM +0100, Florian Westphal wrote:
>> Jiri Pirko <jiri@resnulli.us> wrote:
>> > This patch fixes for example following situation:
>> > On HOSTA do:
>> > ip6tables -I INPUT -p icmpv6 -j DROP
>> > ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>>
>> untested:
>>
>> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> -A INPUT -p icmpv6 -m conntrack --ctstatus CONFIRMED -j ACCEPT
>> -A INPUT -p icmpv6 -j DROP
>>
>> > and on HOSTB you do:
>> > ping6 HOSTA -s2000 (MTU is 1500)
>> >
>> > Incoming echo requests will be filtered out on HOSTA. This issue does
>> > not occur with smaller packets than MTU (where fragmentation does not happen).
>>
>> Patrick, any reason not to kill the special-casing (ct has assigned helper or
>> unconfirmed conntrack) in __ipv6_conntrack_in() ?
>>
>> This should make ipv6 frag behaviour consistent; right now its rather
>> confusing from ruleset point of view, especially the first packet
>> of a connection is always seen as reassembled.
>>
>> So with Jiris rules
>>
>> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> -A INPUT -p icmpv6 -j DROP
>>
>> ping6 -s $bignum works for the first packet but not for subsequent ones
>> which is quite irritating.
>
>Well, the reason was to avoid unnecessary work doing refragmentation
>unless really required. I know its rather complicated, but IPv6 has
>always required treating fragments manually or using conntrack state.
>
>I'm not objecting to changing this, but the patches as they are are
>not the way to go. First, moving nfct_frag to struct sk_buff seems
I'm a bit lost. What "nfct_frag" are you reffering to here?
>like a real waste of space for this quite rare case. Also, we can't
>just use the reassembled packet in ip6tables, when modifying it we
>will still output the unchanged fragments. An last of all, we'll be
>executing the rules on the reassembled packet multiple times, one
>for each fragment.
Reassembled skb would be only used for matching where no changes takes
place.
End even though, the matching is now done for each fragment skb anyway. The
change is only to do it on different skb. I see no erformance or any
other problem in that.
>
>So if someone wants to change this, simply *only* pass the reassembled
>packet through the netfilter hooks and drop the fragments, as in IPv4.
This is unfortunatelly not possible because in forwarding use case, the
fragments have to be send out as they come in.
^ permalink raw reply
* Re: [PATCH v2 0/2] l2 hardware accelerated macvlans
From: John Fastabend @ 2013-11-05 15:17 UTC (permalink / raw)
To: Vlad Yasevich
Cc: nhorman, alexander.h.duyck, netdev, andy, davem,
jeffrey.t.kirsher
In-Reply-To: <5279051B.6000406@gmail.com>
On 11/5/2013 6:47 AM, Vlad Yasevich wrote:
> Hi John
>
[...]
>> series. It would be best (I think) to use the software
>> path for macvlan to macvlan traffic and save the PCIe
>> bus. Also this only allows for layer 2 mac forwarding
>> where some hardware supports more interesting forwarding
>> capabilities. Integrating with OVS may be useful here.
>
> This seems to be saying that for macvlan-macvlan
> case, you still prefere to do software based forwarding, but
> patch 1 in the series seem to always attempt to do hardware
> offloaded forwarding regardless of traffic and macvlan type.
> Can you clarify.
>
> Thanks
> -vlad
>
This series always attempts to do hardware offload even in the
macvlan-macvlan case as you note. I'm suggesting a further
optimization might be to use the software based forwarding in
this case. My plan is to investigate this after I get the initial
series completed.
.John
^ permalink raw reply
* Re: [PATCH v2 0/2] l2 hardware accelerated macvlans
From: Vlad Yasevich @ 2013-11-05 15:20 UTC (permalink / raw)
To: John Fastabend
Cc: nhorman, alexander.h.duyck, netdev, andy, davem,
jeffrey.t.kirsher
In-Reply-To: <52790C01.3070107@intel.com>
On 11/05/2013 10:17 AM, John Fastabend wrote:
> On 11/5/2013 6:47 AM, Vlad Yasevich wrote:
>> Hi John
>>
>
> [...]
>
>>> series. It would be best (I think) to use the software
>>> path for macvlan to macvlan traffic and save the PCIe
>>> bus. Also this only allows for layer 2 mac forwarding
>>> where some hardware supports more interesting forwarding
>>> capabilities. Integrating with OVS may be useful here.
>>
>> This seems to be saying that for macvlan-macvlan
>> case, you still prefere to do software based forwarding, but
>> patch 1 in the series seem to always attempt to do hardware
>> offloaded forwarding regardless of traffic and macvlan type.
>> Can you clarify.
>>
>> Thanks
>> -vlad
>>
>
> This series always attempts to do hardware offload even in the
> macvlan-macvlan case as you note. I'm suggesting a further
> optimization might be to use the software based forwarding in
> this case. My plan is to investigate this after I get the initial
> series completed.
>
Ahh. Got it.
Thanks
-vlad
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Florian Westphal @ 2013-11-05 15:39 UTC (permalink / raw)
To: Jiri Pirko
Cc: Patrick McHardy, Florian Westphal, netdev, davem, pablo,
netfilter-devel, yoshfuji, kadlec, mleitner, kuznet, jmorris,
wensong, horms, ja, edumazet, pshelar, jasowang,
alexander.h.duyck, coreteam
In-Reply-To: <20131105150115.GB2438@minipsycho.orion>
Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
> >executing the rules on the reassembled packet multiple times, one
> >for each fragment.
>
[..]
> End even though, the matching is now done for each fragment skb anyway. The
> change is only to do it on different skb. I see no erformance or any
> other problem in that.
One problem that comes to mind is that nfacct or quota match will
now account num_of_fragments * length_of_reassemled_skb bytes.
^ 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