* [PATCH 1/2 net-next] net: Export skb_zerocopy() to zerocopy from one skb to another
From: Thomas Graf @ 2013-11-08 10:47 UTC (permalink / raw)
To: jesse, davem; +Cc: dev, netdev, eric.dumazet
In-Reply-To: <cover.1383906944.git.tgraf@suug.ch>
Make the skb zerocopy logic written for nfnetlink queue available for
use by other modules.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
include/linux/skbuff.h | 3 ++
net/core/skbuff.c | 85 ++++++++++++++++++++++++++++++++++++
net/netfilter/nfnetlink_queue_core.c | 59 ++-----------------------
3 files changed, 92 insertions(+), 55 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 036ec7d..9e6a293 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2372,6 +2372,9 @@ int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
struct pipe_inode_info *pipe, unsigned int len,
unsigned int flags);
void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to);
+unsigned int skb_zerocopy_headlen(const struct sk_buff *from);
+void skb_zerocopy(struct sk_buff *to, const struct sk_buff *from,
+ int len, int hlen);
void skb_split(struct sk_buff *skb, struct sk_buff *skb1, const u32 len);
int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen);
void skb_scrub_packet(struct sk_buff *skb, bool xnet);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 8c5197f..c5cefbe 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2125,6 +2125,91 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset,
}
EXPORT_SYMBOL(skb_copy_and_csum_bits);
+ /**
+ * skb_zerocopy_headlen - Calculate headroom needed for skb_zerocopy()
+ * @from: source buffer
+ *
+ * Calculates the amount of linear headroom needed in the 'to' skb passed
+ * into skb_zerocopy().
+ */
+unsigned int
+skb_zerocopy_headlen(const struct sk_buff *from)
+{
+ unsigned int hlen = 0;
+
+ if (!from->head_frag ||
+ skb_headlen(from) < L1_CACHE_BYTES ||
+ skb_shinfo(from)->nr_frags >= MAX_SKB_FRAGS)
+ hlen = skb_headlen(from);
+
+ if (skb_has_frag_list(from))
+ hlen = from->len;
+
+ return hlen;
+}
+EXPORT_SYMBOL_GPL(skb_zerocopy_headlen);
+
+/**
+ * skb_zerocopy - Zero copy skb to skb
+ * @to: destination buffer
+ * @source: source buffer
+ * @len: number of bytes to copy from source buffer
+ * @hlen: size of linear headroom in destination buffer
+ *
+ * Copies up to `len` bytes from `from` to `to` by creating references
+ * to the frags in the source buffer.
+ *
+ * The `hlen` as calculated by skb_zerocopy_headlen() specifies the
+ * headroom in the `to` buffer.
+ */
+void
+skb_zerocopy(struct sk_buff *to, const struct sk_buff *from, int len, int hlen)
+{
+ int i, j = 0;
+ int plen = 0; /* length of skb->head fragment */
+ struct page *page;
+ unsigned int offset;
+
+ BUG_ON(!from->head_frag && !hlen);
+
+ /* dont bother with small payloads */
+ if (len <= skb_tailroom(to)) {
+ skb_copy_bits(from, 0, skb_put(to, len), len);
+ return;
+ }
+
+ if (hlen) {
+ skb_copy_bits(from, 0, skb_put(to, hlen), hlen);
+ len -= hlen;
+ } else {
+ plen = min_t(int, skb_headlen(from), len);
+ if (plen) {
+ page = virt_to_head_page(from->head);
+ offset = from->data - (unsigned char *)page_address(page);
+ __skb_fill_page_desc(to, 0, page, offset, plen);
+ get_page(page);
+ j = 1;
+ len -= plen;
+ }
+ }
+
+ to->truesize += len + plen;
+ to->len += len + plen;
+ to->data_len += len + plen;
+
+ for (i = 0; i < skb_shinfo(from)->nr_frags; i++) {
+ if (!len)
+ break;
+ skb_shinfo(to)->frags[j] = skb_shinfo(from)->frags[i];
+ skb_shinfo(to)->frags[j].size = min_t(int, skb_shinfo(to)->frags[j].size, len);
+ len -= skb_shinfo(to)->frags[j].size;
+ skb_frag_ref(to, j);
+ j++;
+ }
+ skb_shinfo(to)->nr_frags = j;
+}
+EXPORT_SYMBOL_GPL(skb_zerocopy);
+
void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to)
{
__wsum csum;
diff --git a/net/netfilter/nfnetlink_queue_core.c b/net/netfilter/nfnetlink_queue_core.c
index 21258cf..615ee12 100644
--- a/net/netfilter/nfnetlink_queue_core.c
+++ b/net/netfilter/nfnetlink_queue_core.c
@@ -235,51 +235,6 @@ nfqnl_flush(struct nfqnl_instance *queue, nfqnl_cmpfn cmpfn, unsigned long data)
spin_unlock_bh(&queue->lock);
}
-static void
-nfqnl_zcopy(struct sk_buff *to, const struct sk_buff *from, int len, int hlen)
-{
- int i, j = 0;
- int plen = 0; /* length of skb->head fragment */
- struct page *page;
- unsigned int offset;
-
- /* dont bother with small payloads */
- if (len <= skb_tailroom(to)) {
- skb_copy_bits(from, 0, skb_put(to, len), len);
- return;
- }
-
- if (hlen) {
- skb_copy_bits(from, 0, skb_put(to, hlen), hlen);
- len -= hlen;
- } else {
- plen = min_t(int, skb_headlen(from), len);
- if (plen) {
- page = virt_to_head_page(from->head);
- offset = from->data - (unsigned char *)page_address(page);
- __skb_fill_page_desc(to, 0, page, offset, plen);
- get_page(page);
- j = 1;
- len -= plen;
- }
- }
-
- to->truesize += len + plen;
- to->len += len + plen;
- to->data_len += len + plen;
-
- for (i = 0; i < skb_shinfo(from)->nr_frags; i++) {
- if (!len)
- break;
- skb_shinfo(to)->frags[j] = skb_shinfo(from)->frags[i];
- skb_shinfo(to)->frags[j].size = min_t(int, skb_shinfo(to)->frags[j].size, len);
- len -= skb_shinfo(to)->frags[j].size;
- skb_frag_ref(to, j);
- j++;
- }
- skb_shinfo(to)->nr_frags = j;
-}
-
static int
nfqnl_put_packet_info(struct sk_buff *nlskb, struct sk_buff *packet,
bool csum_verify)
@@ -304,7 +259,7 @@ nfqnl_build_packet_message(struct net *net, struct nfqnl_instance *queue,
{
size_t size;
size_t data_len = 0, cap_len = 0;
- int hlen = 0;
+ unsigned int hlen = 0;
struct sk_buff *skb;
struct nlattr *nla;
struct nfqnl_msg_packet_hdr *pmsg;
@@ -356,14 +311,8 @@ nfqnl_build_packet_message(struct net *net, struct nfqnl_instance *queue,
if (data_len > entskb->len)
data_len = entskb->len;
- if (!entskb->head_frag ||
- skb_headlen(entskb) < L1_CACHE_BYTES ||
- skb_shinfo(entskb)->nr_frags >= MAX_SKB_FRAGS)
- hlen = skb_headlen(entskb);
-
- if (skb_has_frag_list(entskb))
- hlen = entskb->len;
- hlen = min_t(int, data_len, hlen);
+ hlen = skb_zerocopy_headlen(entskb);
+ hlen = min_t(unsigned int, hlen, data_len);
size += sizeof(struct nlattr) + hlen;
cap_len = entskb->len;
break;
@@ -504,7 +453,7 @@ nfqnl_build_packet_message(struct net *net, struct nfqnl_instance *queue,
nla->nla_type = NFQA_PAYLOAD;
nla->nla_len = nla_attr_size(data_len);
- nfqnl_zcopy(skb, entskb, data_len, hlen);
+ skb_zerocopy(skb, entskb, data_len, hlen);
}
nlh->nlmsg_len = skb->len;
--
1.8.3.1
^ permalink raw reply related
* RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
From: David Laight @ 2013-11-08 10:47 UTC (permalink / raw)
To: Sarah Sharp; +Cc: netdev, linux-usb
In-Reply-To: <20131108001838.GB11529@xanatos>
> From: Sarah Sharp [mailto:sarah.a.sharp@linux.intel.com]
> On Thu, Nov 07, 2013 at 05:20:49PM -0000, David Laight wrote:
> >
> > Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
> > can only occur at a boundary between underlying USB frames (512 bytes for 480M).
>
> Which version of the spec are you looking at? I'm looking at the
> updated version from 08/2012 and I don't see any such requirement.
The copy I downloaded last week is dated 5/21/10, seems the copy on the
web site hasn't been updated.
> I do see that section says "A TD Fragment shall not span Transfer Ring
> Segments" where a TD fragment is defined as exact multiples of Max Burst
> Size * Max Packet Size bytes for the endpoint. Is that what you mean
> about USB frames?
That is the clause, it needs some understanding.
Figure 24 shows a correctly aligned link TRB - one where the TRB boundary
is aligned with a packet boundary (512 bytes at 480M, 1k at 5G etc).
> > If this isn't done the USB frames aren't formatted correctly and, for example,
> > the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
> > when running a netperf tcp transmit test with (say) and 8k buffer.
>
> Which driver does that use? Is it using the scatter gather list
> mechanism for URBs (i.e. urb->sg)? Or is it submitting multiple URBs
> for fragmented buffers? Or is it submitting isochronous URBs with
> multiple frames? Or is it submitting bulk URBs with one transfer buffer
> that crosses the 64KB boundary?
>
> I'm trying to understand what the USB device driver is doing in order to
> create multi-TRB TDs that would violate the TD fragment rules.
The usb setup is done by net/usbnet.c, the ax88179_178a driver just adds
a header to the ethernet frame. Since the hardware support TCP segment
offload the urb->sg list is used, the first fragment seems to be 1578
bytes and is followed by two or three fragments (split on an 0x8000
boundary) making up the rest of the 65234 bytes.
(I haven't yet seen a buffer that crossed a 64k boundary).
I'm running netperf - which is doing a burst of 8k sends into
a TCP socket.
> > While this change improves things a lot (it runs for 20 minutes rather than
> > a few seconds), there is still something else wrong.
> >
> > This should be a candidate for stable, the ax88179_178a driver defaults to
> > gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
>
> I want to understand what the larger issue is here before pushing
> bandaid fixes.
>
> I don't think this is the right approach, because prepare_ring() can be
> called for isochronous URBs that get mapped to multiple TDs. The TD
> fragment rules only apply to one TD, so failing URB submission because
> many isochronous TDs span more than one ring segment doesn't seem like
> the right approach. Inserting no-op TRBs will also result in odd
> isochronous behavior, since a no-op TRB means the xHC should not send or
> request an isochronous packet for that service interval.
I wasn't aware of that effect of NOP TRB on isoc data.
Three obvious options:
1) Pass an extra parameter indicating that the caller will handle an
TRB data alignment issues at the link TRB.
2) Add a test for bulk endpoints (ok until the isoc code gets modified
to support SG data).
3) Copy the LINK TRB instead of adding NOPs (would require the rest of
the code use the ring length instead of reading the TRB type).
The second is probably the easiest way to isolate the change.
However there could be problems on an isoc endpoint if the data
crosses a 64k boundary.
> The patch also doesn't address the underlying issue of constructing
> multi-TRB TDs so that it fits the TD fragment rules. Your patch ensures
> there are no link TRBs in the middle of a TD, but it doesn't ensure that
> the TRBs in the TD are exact multiples of the Max Burst Size * Max
> Packet Size bytes for the endpoint.
That doesn't matter, look at figure 25. A TD can be any number of USB
packets and any number or TRB. The constraint is that a TD cannot
contain a LINK TRB.
> Instead, new code in count_sg_trbs_needed() should break the TD into
> proper TD fragments. The queueing code for all endpoints would also
> have to follow those rules. This would have to happen while still
> respecting the 64KB boundary rule.
>
> The driver would also have to make sure that TD fragments didn't have
> link TRBs in them. That's an issue, since the spec decidedly unclear
> about what exactly comprises a TD fragment. Is the xHC host greedy, and
> will lump all multiples into one TD fragment? Or will it assume the TD
> fragment has ended once it consumes one multiple of Max Burst Size * Max
> Packet Size bytes?
It only matters at a LINK TRB (unless you want to request an interrupt).
The constraint seems to be that the data TRB before a link TRB must end
on a MBP boundary.
> This ambiguity means it's basically impossible to figure out whether a
> TD with a link TRB in the middle is constructed properly. The xHCI spec
> architect didn't have a good solution to this problem, so I punted and
> never implemented TD fragments.
The problem is that the hardware does implement them:-)
> If this is really an issue, it's going to be pretty complex to solve.
I thought about solutions and then decided it was easiest to skip to
the next ring segment. The data could be scanned for an earlier
boundary that was aligned, but it really didn't seem worth the effort.
If all of the TRB reference buffers that are larger than MBP then,
when the LINK is encountered, the previous TRB can be split on its
last MBP boundary, if not a bounce buffer would have to be used
(and the code doesn't really know if this a tx or rx transaction).
I've a tx that is split 1576/328/32768/30560 where the 328 could
not be split - so this does happen.
>
> > Signed-off-by: David Laight <david.laight@aculab.com>
> > ---
> >
> > Although I've got a USB2 analyser its trigger and trace stuff is almost
> > unusable! In any case this fails much faster on USB3 (Intel i7 cpu).
>
> I thought you were using a big endian system?
No - I was just reading the code and spotted the endianness bug.
David
> > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > index 5480215..23abc9b 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -2927,8 +2932,43 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
> > }
> >
> > while (1) {
> > - if (room_on_ring(xhci, ep_ring, num_trbs))
> > - break;
> > + if (room_on_ring(xhci, ep_ring, num_trbs)) {
> > + union xhci_trb *trb = ep_ring->enqueue;
> > + unsigned int usable = ep_ring->enq_seg->trbs +
> > + TRBS_PER_SEGMENT - 1 - trb;
> > + u32 nop_cmd;
> > +
> > + /*
> > + * Section 4.11.7.1 TD Fragments states that a link
> > + * TRB must only occur at the boundary between
> > + * data bursts (eg 512 bytes for 480M).
> > + * While it is possible to split a large fragment
> > + * we don't know the size yet.
> > + * Simplest solution is to fill the trb before the
> > + * LINK with nop commands.
> > + */
> > + if (num_trbs == 1 || num_trbs <= usable || usable == 0)
> > + break;
> > +
> > + if (num_trbs >= TRBS_PER_SEGMENT) {
> > + xhci_err(xhci, "Too many fragments %d, max %d\n",
> > + num_trbs, TRBS_PER_SEGMENT - 1);
> > + return -ENOMEM;
> > + }
> > +
> > + nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
> > + ep_ring->cycle_state);
> > + for (; !TRB_TYPE_LINK_LE32(trb->link.control); trb++) {
> > + trb->generic.field[0] = 0;
> > + trb->generic.field[1] = 0;
> > + trb->generic.field[2] = 0;
> > + trb->generic.field[3] = nop_cmd;
> > + ep_ring->num_trbs_free--;
> > + }
> > + ep_ring->enqueue = trb;
> > + if (room_on_ring(xhci, ep_ring, num_trbs))
> > + break;
> > + }
> >
> > if (ep_ring == xhci->cmd_ring) {
> > xhci_err(xhci, "Do not support expand command ring\n");
>
> Sarah Sharp
^ permalink raw reply
* Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: Steffen Klassert @ 2013-11-08 11:01 UTC (permalink / raw)
To: Christophe Gouault
Cc: David S. Miller, Herbert Xu, netdev, Saurabh Mohan,
Sergei Shtylyov, Eric Dumazet
In-Reply-To: <527B8DC5.6080702@6wind.com>
On Thu, Nov 07, 2013 at 01:55:33PM +0100, Christophe Gouault wrote:
> Hello Steffen,
>
> I am also interested in knowing Saurabh's intentions regarding the
> behavior of policies bound to vti interfaces.
>
> However, please note that setting a policy with a wildcard selector
> works in both cases (before or after this patch), so a common test
> case can be defined.
Yes, I looked at the Cisco vti documents but all examples I found use
wildcard selectors which work for both. So I'm still not sure which
version is the right one. Let's wait on Saurabh's explaination.
>
> Actually the *previous* patch on vti (7263a5187f9e vti: get rid of
> nf mark rule in prerouting) introduced significant changes, and
> implies behaviors dependant on the kernel version, but it seemed to
> meet Saurabh's agreement, as the following thread witnesses:
>
> http://www.spinics.net/lists/netdev/msg253134.html
I've just noticed that this went to the stable trees. People who
update a stable kernel want (security) fixes in the first place,
they don't want to change their configuration on the IPsec gateways.
So I think patches that require a configuration change should better
go to net-next, unless it's a urgent fix.
I was not on Cc and it looks like I've overlooked this on the list.
The vti interfaces are pure IPsec interfaces, so perhaps we should
add them to the IPsec section in the maintainers file (maybe together
with the main IPsec protocols esp, ah and ipcomp, which are also not
listed there).
David, would you agree with such a patch?
^ permalink raw reply
* Re: [PATCH 1/2 net-next] net: Export skb_zerocopy() to zerocopy from one skb to another
From: Daniel Borkmann @ 2013-11-08 11:06 UTC (permalink / raw)
To: Thomas Graf
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <107fca409db2405bf3c650a03ea2254d3d6b63dc.1383906944.git.tgraf-G/eBtMaohhA@public.gmane.org>
On 11/08/2013 11:47 AM, Thomas Graf wrote:
> Make the skb zerocopy logic written for nfnetlink queue available for
> use by other modules.
>
> Signed-off-by: Thomas Graf <tgraf-G/eBtMaohhA@public.gmane.org>
Reviewed-by: Daniel Borkmann <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net_sched: fix some checkpatch errors
From: Bjørn Mork @ 2013-11-08 11:04 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Yang Yingliang, davem, netdev, eric.dumazet, jhs, stephen
In-Reply-To: <527B5160.5070700@redhat.com>
Daniel Borkmann <dborkman@redhat.com> writes:
> On 11/07/2013 03:13 AM, Yang Yingliang wrote:
>
>> @@ -263,7 +264,7 @@ void tcf_hash_insert(struct tcf_common *p, struct tcf_hashinfo *hinfo)
>> }
>> EXPORT_SYMBOL(tcf_hash_insert);
>>
>> -static struct tc_action_ops *act_base = NULL;
>> +static struct tc_action_ops *act_base;
>
> From a readability point of view, I think this makes it worse, also the other places
> where you change globals vars like that.
Then you should probably argue for a change to checkpatch. It will make
a lot of noise about such unnecessary initialization.
Bjørn
^ permalink raw reply
* RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
From: David Laight @ 2013-11-08 11:07 UTC (permalink / raw)
To: David Laight, netdev, linux-usb, Sarah Sharp
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73EF@saturn3.aculab.com>
> While this change improves things a lot (it runs for 20 minutes rather than
> a few seconds), there is still something else wrong.
Almost certainly caused by an unrelated local change.
David
^ permalink raw reply
* Re: [PATCH 2/2 net-next] openvswitch: Use skb_zerocopy() for upcall
From: Daniel Borkmann @ 2013-11-08 11:24 UTC (permalink / raw)
To: Thomas Graf
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <9369d871e13fe5b6e468b269450b9f2032a970aa.1383906944.git.tgraf-G/eBtMaohhA@public.gmane.org>
On 11/08/2013 11:47 AM, Thomas Graf wrote:
> Use of skb_zerocopy() avoids the expensive call to memcpy() when
> copying the packet data into the Netlink skb. Completes checksum
> through skb_checksum_help() if needed.
>
> Netlink messaged must be properly padded and aligned to meet
> sanity checks of the user space counterpart.
>
> Cost of memcpy is significantly reduced from:
> + 7.48% vhost-8471 [k] memcpy
> + 5.57% ovs-vswitchd [k] memcpy
> + 2.81% vhost-8471 [k] csum_partial_copy_generic
>
> to:
> + 5.72% ovs-vswitchd [k] memcpy
> + 3.32% vhost-5153 [k] memcpy
> + 0.68% vhost-5153 [k] skb_zerocopy
>
> (megaflows disabled)
>
> Signed-off-by: Thomas Graf <tgraf-G/eBtMaohhA@public.gmane.org>
> Cc: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
> Cc: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Daniel Borkmann <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
^ permalink raw reply
* Re: [PATCHv2 net-next 0/3] Small IPsec fix
From: Steffen Klassert @ 2013-11-08 11:54 UTC (permalink / raw)
To: Fan Du; +Cc: herbert, davem, netdev
In-Reply-To: <1383817670-5783-1-git-send-email-fan.du@windriver.com>
On Thu, Nov 07, 2013 at 05:47:47PM +0800, Fan Du wrote:
> Hi
>
> This patchset made below modifications:
> - Fix setting policy index with "ip xfrm ... index=xx"
> which is currently broken
>
> - Using correct name space for home agent when migrating
> key info.
>
> - Put xfrm locks into per namespace to improve scalability.
>
> Changelog:
> v2:
> xfrm: Namespacify xfrm state/policy locks
> -Fix compile error when CONFIG_NET_NS is unset, thanks for the lovely build robot.
>
> Fan Du (3):
> xfrm: Try to honor policy index if it's supplied by user
> xfrm: Using the right namespace to migrate key info
> xfrm: Namespacify xfrm state/policy locks
Your patches are currently in the ipsec-next testing branch.
linux-next should not contain v3.14 material at the moment,
so I'll wait until after the merge window before I'm pushing
them to the master branch. No further action from your side
required.
Thanks, Fan!
^ permalink raw reply
* Re: [ethtool] ethtool: ixgbe DCB registers dump for 82599 and x540
From: Jeff Kirsher @ 2013-11-08 12:01 UTC (permalink / raw)
To: bhutchings; +Cc: Leonardo Potenza, netdev, gospo, sassmann, Maryam Tahhan
In-Reply-To: <1380787887-6878-1-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]
On Thu, 2013-10-03 at 01:11 -0700, Jeff Kirsher wrote:
> From: Leonardo Potenza <leonardo.potenza@intel.com>
>
> Added support for DCB registers dump using ethtool -d option both for
> 82599 and x540 ethernet controllers
>
> Signed-off-by: Leonardo Potenza <leonardo.potenza@intel.com>
> Signed-off-by: Maryam Tahhan <maryam.tahhan@intel.com>
> Acked-by: John Fastabend <john.r.fastabend@intel.com>
> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
> Tested-by: Jack Morgan <jack.morgan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> ixgbe.c | 154
> ++++++++++++++++++++++++++++++++++++++++++++++++++++------------
> 1 file changed, 125 insertions(+), 29 deletions(-)
Ben-
I see you released 3.12 and I do not see this patch in your tree. I
sent it originally on October 3rd, do need me to resend it?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 net-next] inet: fix a UFO regression
From: Eric Dumazet @ 2013-11-08 12:18 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Alexei Starovoitov, David Miller, netdev, Hannes Frederic Sowa
In-Reply-To: <527C877D.3080309@gmail.com>
On Thu, 2013-11-07 at 22:41 -0800, Sridhar Samudrala wrote:
> Does this fix also help vxlan performance between 2 VMs on 2 different
> physical m/cs across 10G NIC?
> What is the throughput you are seeing via 10G nics?
> With linux 3.12, i am only seeing around 2Gbps (iperf TCP_STREAM with
> 16K messages) between 2 VMs when using vxlan across a 10G nic.
> Is this due to the overhead of software GSO and not doing GRO at the
> receiver?
What NIC is used at sender, what NIC is used at receiver ?
If you use GRE instead of VXLAN, do you get any difference in speed ?
^ permalink raw reply
* Re: [PATCH net-next v3 1/3] ipv6: enable IPV6_FLOWLABEL_MGR for getsockopt
From: Hannes Frederic Sowa @ 2013-11-08 12:27 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1383843194-22945-1-git-send-email-florent.fourcot@enst-bretagne.fr>
On Thu, Nov 07, 2013 at 05:53:12PM +0100, Florent Fourcot wrote:
> 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
>
> v3:
> * move the spin_lock to protect only the
> relevant code
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
There still are some locking anomalies in ip6_flowlabel. But none
has something to do with your patches. E.g. mem_check runs without
rcu_read_lock.
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] ipv6: protect flow label renew against GC
From: Hannes Frederic Sowa @ 2013-11-08 12:29 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1383843194-22945-3-git-send-email-florent.fourcot@enst-bretagne.fr>
On Thu, Nov 07, 2013 at 05:53:14PM +0100, Florent Fourcot wrote:
> Take ip6_fl_lock before to read and update
> a label.
>
> v2: protect only the relevant code
>
> Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks for fixing this,
Hannes
^ permalink raw reply
* Re: [net-next PATCH 1/2] ixgbe: fix build err, num_rx_queues is only available with CONFIG_RPS
From: Neil Horman @ 2013-11-08 12:29 UTC (permalink / raw)
To: John Fastabend; +Cc: jeffrey.t.kirsher, netdev, davem
In-Reply-To: <20131108085031.6935.61765.stgit@nitbit.x32>
On Fri, Nov 08, 2013 at 12:50:32AM -0800, John Fastabend wrote:
> In the recent support for layer 2 hardware acceleration, I added a
> few references to real_num_rx_queues and num_rx_queues which are
> only available with CONFIG_RPS.
>
> The fix is first to remove unnecessary references to num_rx_queues.
> Because the hardware offload case is limited to cases where RX queues
> and TX queues are equal we only need a single check. Then wrap the
> single case in an ifdef.
>
> The patch that introduce this is here,
>
> commit a6cc0cfa72e0b6d9f2c8fd858aacc32313c4f272
> Author: John Fastabend <john.r.fastabend@intel.com>
> Date: Wed Nov 6 09:54:46 2013 -0800
>
> net: Add layer 2 hardware acceleration operations for macvlan devices
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [net-next PATCH 2/2] ixgbe: deleting dfwd stations out of order can cause null ptr deref
From: Neil Horman @ 2013-11-08 12:31 UTC (permalink / raw)
To: John Fastabend; +Cc: jeffrey.t.kirsher, netdev, davem
In-Reply-To: <20131108085109.6935.99661.stgit@nitbit.x32>
On Fri, Nov 08, 2013 at 12:51:10AM -0800, John Fastabend wrote:
> The number of stations in use is kept in the num_rx_pools counter
> in the ixgbe_adapter structure. This is in turn used by the queue
> allocation scheme to determine how many queues are needed to support
> the number of pools in use with the current feature set.
>
> This works as long as the pools are added and destroyed in order
> because (num_rx_pools * queues_per_pool) is equal to the last
> queue in use by a pool. But as soon as you delete a pool out of
> order this is no longer the case. So the above multiplication
> allocates to few queues and a pool may reference a ring that has
> not been allocated/initialized.
>
> To resolve use the bit mask of in use pools to determine the final
> pool being used and allocate enough queues so that we don't
> inadvertently remove its queues.
>
> # ip link add link eth2 \
> numtxqueues 4 numrxqueues 4 txqueuelen 50 type macvlan
> # ip link set dev macvlan0 up
> # ip link add link eth2 \
> numtxqueues 4 numrxqueues 4 txqueuelen 50 type macvlan
> # ip link set dev macvlan1 up
> # for i in {0..100}; do
> ip link set dev macvlan0 down; ip link set dev macvlan0 up;
> done;
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] sctp: do some clean ups
From: Neil Horman @ 2013-11-08 12:31 UTC (permalink / raw)
To: Wang Weidong; +Cc: vyasevich, davem, dingtianhong, linux-sctp, netdev
In-Reply-To: <1383891471-20892-1-git-send-email-wangweidong1@huawei.com>
On Fri, Nov 08, 2013 at 02:17:47PM +0800, Wang Weidong wrote:
> This patch series include: remove the duplicate initialize,
> make code simple, convert func to boolean, fix some typos.
>
> v1 -> v2:
> - patch2: make the code more simplification, as suggested
> by Joe Perches.
>
> Wang Weidong (4):
> sctp: remove the duplicate initialize
> sctp: remove the else path
> sctp: convert sctp_peer_needs_update to boolean
> sctp: fix some comments in associola.c
>
> net/sctp/associola.c | 65 ++++++++--------------------------------------------
> 1 file changed, 10 insertions(+), 55 deletions(-)
>
> --
> 1.7.12
>
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next 2/3] ipv6: increase maximum lifetime of flow labels
From: Hannes Frederic Sowa @ 2013-11-08 12:34 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1383843194-22945-2-git-send-email-florent.fourcot@enst-bretagne.fr>
On Thu, Nov 07, 2013 at 05:53:13PM +0100, Florent Fourcot wrote:
> 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 between
> reattribution of 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 increase the maximum linger to 150
> seconds, allowing more flexibility to standard
> users.
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: [net-next PATCH 1/2] ixgbe: fix build err, num_rx_queues is only available with CONFIG_RPS
From: Jeff Kirsher @ 2013-11-08 12:35 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev, davem, nhorman
In-Reply-To: <20131108085031.6935.61765.stgit@nitbit.x32>
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
On Fri, 2013-11-08 at 00:50 -0800, John Fastabend wrote:
> In the recent support for layer 2 hardware acceleration, I added a
> few references to real_num_rx_queues and num_rx_queues which are
> only available with CONFIG_RPS.
>
> The fix is first to remove unnecessary references to num_rx_queues.
> Because the hardware offload case is limited to cases where RX queues
> and TX queues are equal we only need a single check. Then wrap the
> single case in an ifdef.
>
> The patch that introduce this is here,
>
> commit a6cc0cfa72e0b6d9f2c8fd858aacc32313c4f272
> Author: John Fastabend <john.r.fastabend@intel.com>
> Date: Wed Nov 6 09:54:46 2013 -0800
>
> net: Add layer 2 hardware acceleration operations for macvlan
> devices
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [net-next PATCH 2/2] ixgbe: deleting dfwd stations out of order can cause null ptr deref
From: Jeff Kirsher @ 2013-11-08 12:36 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev, davem, nhorman
In-Reply-To: <20131108085109.6935.99661.stgit@nitbit.x32>
[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]
On Fri, 2013-11-08 at 00:51 -0800, John Fastabend wrote:
> The number of stations in use is kept in the num_rx_pools counter
> in the ixgbe_adapter structure. This is in turn used by the queue
> allocation scheme to determine how many queues are needed to support
> the number of pools in use with the current feature set.
>
> This works as long as the pools are added and destroyed in order
> because (num_rx_pools * queues_per_pool) is equal to the last
> queue in use by a pool. But as soon as you delete a pool out of
> order this is no longer the case. So the above multiplication
> allocates to few queues and a pool may reference a ring that has
> not been allocated/initialized.
>
> To resolve use the bit mask of in use pools to determine the final
> pool being used and allocate enough queues so that we don't
> inadvertently remove its queues.
>
> # ip link add link eth2 \
> numtxqueues 4 numrxqueues 4 txqueuelen 50 type macvlan
> # ip link set dev macvlan0 up
> # ip link add link eth2 \
> numtxqueues 4 numrxqueues 4 txqueuelen 50 type macvlan
> # ip link set dev macvlan1 up
> # for i in {0..100}; do
> ip link set dev macvlan0 down; ip link set dev macvlan0 up;
> done;
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [net-next PATCH 0/2] ixgbe: macvlan fixes
From: Jeff Kirsher @ 2013-11-08 12:39 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev, davem, nhorman
In-Reply-To: <20131108084654.6935.36501.stgit@nitbit.x32>
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
On Fri, 2013-11-08 at 00:50 -0800, John Fastabend wrote:
> Two additional fixes for ixgbe l2 forwarding acceleration. One
> was reported by kbuild build bot and the second after hardening
> my test scripts.
>
> Typically I would send ixgbe fixes through JeffK's tree but I
> know a few people who are looking at the feature in their setup's
> so wanted to be sure the patches were visible.
I told John to go ahead and send these patches directly to netdev, so
that Dave can pick these up before he pushes his net-next to Linus.
>
> For reference the ixgbe accelerated macvlan patch is here:
>
> commit 2a47fa45d4dfbc54659d28de311a1f764b296a3c
> Author: John Fastabend <john.r.fastabend@intel.com>
> Date: Wed Nov 6 09:54:52 2013 -0800
>
> ixgbe: enable l2 forwarding acceleration for macvlans
>
> Thanks,
> John
>
> ---
>
> John Fastabend (2):
> ixgbe: fix build err, num_rx_queues is only available with CONFIG_RPS
> ixgbe: deleting dfwd stations out of order can cause null ptr deref
>
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ipv6: use rt6_get_dflt_router to get default router in rt6_route_rcv
From: Hannes Frederic Sowa @ 2013-11-08 12:43 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev
In-Reply-To: <527C44E5.70606@cn.fujitsu.com>
On Fri, Nov 08, 2013 at 09:56:53AM +0800, Duan Jiong wrote:
>
> As the rfc 4191 said, the Router Preference and Lifetime values in a
> ::/0 Route Information Option should override the preference and lifetime
> values in the Router Advertisement header. But when the kernel deals with
> a ::/0 Route Information Option, the rt6_get_route_info() always return
> NULL, that means that overriding will not happen, because those default
> routers were added without flag RTF_ROUTEINFO in rt6_add_dflt_router().
>
> In order to deal with that condition, we should call rt6_get_dflt_router
> when the prefix length is 0.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: Christophe Gouault @ 2013-11-08 12:55 UTC (permalink / raw)
To: David Miller, steffen.klassert
Cc: herbert, netdev, saurabh.mohan, sergei.shtylyov, eric.dumazet
In-Reply-To: <20131107.181723.1978438697370768133.davem@davemloft.net>
Hi David,
On 11/08/2013 12:17 AM, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Thu, 7 Nov 2013 12:25:49 +0100
>
>> On Wed, Nov 06, 2013 at 09:05:53AM +0100, Christophe Gouault wrote:
>>> The vti interface inbound and outbound SPD lookups are based on the
>>> ipsec packet instead of the plaintext packet.
>>>
>>> Not only is it counterintuitive, it also restricts vti interfaces
>>> to a single policy (whose selector must match the tunnel local and
>>> remote addresses).
>>>
>>> The policy selector is supposed to match the plaintext packet, before
>>> encryption or after decryption.
>>>
>>> This patch performs the SPD lookup based on the plaintext packet. It
>>> enables to create several polices bound to the vti interface (via a
>>> mark equal to the vti interface okey).
>>>
>>> It remains possible to apply the same policy to all packets entering
>>> the vti interface, by setting an any-to-any selector (src 0.0.0.0/0
>>> dst 0.0.0.0/0 proto any mark OKEY).
>>>
>>> Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
>> Hm, this patch breaks my current vti test setup. I would need to
>> configure the policies and states dependent on the kernel version
>> if we apply this patch...
>>
>> It would be good to hear from the original author of the vti code
>> whether the current behaviour is intentional before we do anything
>> here.
> I'm disappointed that we're breaking IPSEC semantics several times.
> This really isn't acceptable at all, not even remotely.
I understand your disappointment, however this patch precisely aims at
*restoring* theIPsec semantics:
the original vti code uses the SP selector to match the ipsec encrypted
packetinstead of the plaintext packet, which is contrary to the IPsec
semantics.
> The fact that a developer has a configuration he was actually
> using, and would be broken by this patch, says to me that there
> is absolutely no way I can apply this.
As wrote Steffen Klassert, it would be good to hear from the original
author ofthe vti code (Saurabh Mohan) whether the current behaviour is
intentional.
It would also be good to know how many people currently use vti, but my
feeling is that vti is still at an experimental stage.
Best Regards,
Christophe
> Sorry.
^ permalink raw reply
* Re: [RFC] tcp: randomize TCP source ports
From: Hannes Frederic Sowa @ 2013-11-08 13:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1383872049.9412.124.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Nov 07, 2013 at 04:54:09PM -0800, Eric Dumazet wrote:
> TCP does proper randomization of ports on active connections only if
> bind() is used between socket() and connect()
>
> If bind() is not specifically used, kernel performs autobind, and TCP
> autobind typically uses a sequential allocation for a given (dst
> address, dst port, src address) tuple.
>
> UDP autobind does a randomization, as part of the effort to make DNS
> more secure.
If I understand the code correctly the UDP ports are fully randomized? This
is good as per-peer randomization and then incrementation seems to be
theoretically broken:
<https://sites.google.com/site/hayashulman/files/NIC-derandomisation.pdf>
Looking at the code I somehow would like to check the use of net_random there.
The prandom function is reseeded as late_initcall and then only seeded by some
network addresses.
At the time the late_initcall reseeds the PRNG my tests have shown that
the nonblockingpool was still not fully initialized where the PRNG gets
reseeded from.
Hm, I propose a patch which does reseed the pool as soon as the nonblocking
pool got credited enough entropy in credit_entropy_bits. This should help
later binds().
> TCP autobind uses a global sequential number (called @hint in source
> code) with a perturbation done by secure_ipv4_port_ephemeral(),
> so that the 'hint' of the next port is per (saddr, daddr, dport) tuple
>
> This was probably done to maximize port use and avoid hitting timewait
> sockets, but I think it should be OK to replace this stuff by a random
> selection to have more entropy in the various flow hashing functions,
> and in general higher security levels. TCP timestamps are now well
> deployed.
We recently had a thread that Windows (since Vista?) disabled tcp
timestamps by default. But I don't see how this should make a great
difference (and still wonder why they give up PAWS.)
> Patch would be trivial, but I'd like to get some comments if
> you think this idea is wrong.
I would like to see this happening.
Thanks,
Hannes
^ permalink raw reply
* [PATCH net 0/2] macvlan: disable LRO on lowerdev instead of a macvlan
From: Michal Kubecek @ 2013-11-08 13:40 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy
A customer of ours encountered a problem with LRO on an ixgbe network
card. Analysis showed that it was a known conflict of forwarding and LRO
but the forwarding was enabled in an LXC container where only a macvlan
was, not the ethernet device itself.
I believe the solution is exactly the same as what we do for "normal"
(802.1q) VLAN devices: if dev_disable_lro() is called for such device,
LRO is disabled on the underlying "real" device instead.
Michal Kubecek (2):
macvlan: introduce IFF_MACVLAN flag and helper functions
macvlan: disable LRO on lower device instead of macvlan
drivers/net/macvlan.c | 2 +-
include/linux/if_macvlan.h | 26 ++++++++++++++++++++++++++
include/uapi/linux/if.h | 1 +
net/core/dev.c | 5 +++++
4 files changed, 33 insertions(+), 1 deletion(-)
--
1.8.1.4
^ permalink raw reply
* [PATCH net 1/2] macvlan: introduce IFF_MACVLAN flag and helper functions
From: Michal Kubecek @ 2013-11-08 13:41 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy
In-Reply-To: <cover.1383915401.git.mkubecek@suse.cz>
Introduce IFF_MACVLAN flag to recognize macvlan devices and two
helper functions, is_macvlan_dev() and macvlan_dev_real_dev().
These work like similar functions for 802.1q VLAN devices.
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
drivers/net/macvlan.c | 2 +-
include/linux/if_macvlan.h | 26 ++++++++++++++++++++++++++
include/uapi/linux/if.h | 1 +
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 9bf46bd..3bdac0a 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -685,7 +685,7 @@ void macvlan_common_setup(struct net_device *dev)
ether_setup(dev);
dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE | IFF_TX_SKB_SHARING);
- dev->priv_flags |= IFF_UNICAST_FLT;
+ dev->priv_flags |= IFF_UNICAST_FLT | IFF_MACVLAN;
dev->netdev_ops = &macvlan_netdev_ops;
dev->destructor = free_netdev;
dev->header_ops = &macvlan_hard_header_ops;
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index ddd33fd..8f355f9 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -118,4 +118,30 @@ extern int macvlan_link_register(struct rtnl_link_ops *ops);
extern netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
struct net_device *dev);
+#if IS_ENABLED(CONFIG_MACVLAN)
+static inline bool is_macvlan_dev(struct net_device *dev)
+{
+ return dev->priv_flags & IFF_MACVLAN;
+}
+
+static inline struct net_device *
+macvlan_dev_real_dev(const struct net_device *dev)
+{
+ struct macvlan_dev *macvlan = netdev_priv(dev);
+
+ return macvlan->lowerdev;
+}
+#else
+static inline bool is_macvlan_dev(struct net_device *dev)
+{
+ return false;
+}
+
+static inline struct net_device *
+macvlan_dev_real_dev(const struct net_device *dev)
+{
+ return NULL;
+}
+#endif
+
#endif /* _LINUX_IF_MACVLAN_H */
diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
index 1ec407b..d8e48f8 100644
--- a/include/uapi/linux/if.h
+++ b/include/uapi/linux/if.h
@@ -83,6 +83,7 @@
#define IFF_SUPP_NOFCS 0x80000 /* device supports sending custom FCS */
#define IFF_LIVE_ADDR_CHANGE 0x100000 /* device supports hardware address
* change when it's running */
+#define IFF_MACVLAN 0x200000 /* macvlan device */
#define IF_GET_IFACE 0x0001 /* for querying only */
--
1.8.1.4
^ permalink raw reply related
* [PATCH net 2/2] macvlan: disable LRO on lower device instead of macvlan
From: Michal Kubecek @ 2013-11-08 13:41 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy
In-Reply-To: <cover.1383915401.git.mkubecek@suse.cz>
A macvlan device has always LRO disabled so that calling
dev_disable_lro() on it does nothing. If we need to disable LRO
e.g. because
- the macvlan device is inserted into a bridge
- IPv6 forwarding is enabled for it
- it is in a different namespace than lowerdev and IPv4
forwarding is enabled in it
we need to disable LRO on its underlying device instead (as we
do for 802.1q VLAN devices).
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
net/core/dev.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 3430b1e..4af02a9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -131,6 +131,7 @@
#include <linux/static_key.h>
#include <linux/hashtable.h>
#include <linux/vmalloc.h>
+#include <linux/if_macvlan.h>
#include "net-sysfs.h"
@@ -1425,6 +1426,10 @@ void dev_disable_lro(struct net_device *dev)
if (is_vlan_dev(dev))
dev = vlan_dev_real_dev(dev);
+ /* the same for macvlan devices */
+ if (is_macvlan_dev(dev))
+ dev = macvlan_dev_real_dev(dev);
+
dev->wanted_features &= ~NETIF_F_LRO;
netdev_update_features(dev);
--
1.8.1.4
^ 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