* Re: C45 support and mdiobus_scan
From: Andrew Lunn @ 2018-08-10 16:34 UTC (permalink / raw)
To: Tom Lendacky; +Cc: Jose Abreu, netdev@vger.kernel.org, Florian Fainelli
In-Reply-To: <a7b9fcfe-fbd5-648e-9e38-c66ed6081810@amd.com>
On Fri, Aug 10, 2018 at 10:20:56AM -0500, Tom Lendacky wrote:
> On 8/9/2018 10:25 AM, Andrew Lunn wrote:
> >>> The PCIe core will look in the device tree and when it creates the
> >>> platform device for the i210 on the pcie bus, it points
> >>> pdev->dev.of_node at this node. So long as you are using a platform
> >>> with DT, you can do this. I hope you are not using x86..
> >>
> >> Yes I am :( Any possible solution for this?
>
> I haven't looked too closely, but maybe you can add a new mdiobus_scan
> function for 10G that attempts get_phy_device() with is_c45 set to true
> and if nothing is found falls back to get_phy_device() with is_c45 set to
> false.
Hi Tom
I did consider at one point adding extra flags to the struct mii_bus
to indicate if the bus master supports C22 and or C45, and then scan
the bus as appropriate. We cannot unconditionally do a C45 scan on all
busses, because most bus drivers don't look for MII_ADDR_C45, and so
are wrongly going to do a C22 transaction. There is also one bus
driver i know of which can only do C45. But it at least returns
EOPNOTSUPP if you ask it to do a C22.
I think this needs addressing at some point. We are seeing more 2.5G,
5G and 10G MAC/PHY combinations, and they often need C45. So maybe
adding a flag saying C45 is supported, and then scanning is a good way
forward. Adding a flag saying C22 is supported might be too much work,
without enough return.
> I don't know what would happen if you have a non-c45 phy attached,
> but it's worth a shot to try it and see for each situation.
That should be fine. A C22 PHY should ignore a C45 transaction. At
least that was the design idea when C45 was introduced. But i would
not be too surprised if we find the odd C22 phy get confused, and we
need to add some sort of quirks.
Andrew
^ permalink raw reply
* Re: [PATCH bpf] Revert "xdp: add NULL pointer check in __xdp_return()"
From: Jakub Kicinski @ 2018-08-10 16:26 UTC (permalink / raw)
To: Björn Töpel
Cc: Daniel Borkmann, Alexei Starovoitov, Netdev, Taehee Yoo,
Jesper Dangaard Brouer, Björn Töpel, Karlsson, Magnus,
Magnus Karlsson, kafai
In-Reply-To: <CAJ+HfNjRKB3e6zAO1CwSCPOkMon8ztEr70f-Z2WJ3chtOZSKCg@mail.gmail.com>
On Fri, 10 Aug 2018 17:16:45 +0200, Björn Töpel wrote:
> Den fre 10 aug. 2018 kl 16:10 skrev Daniel Borkmann <daniel@iogearbox.net>:
> >
> > On 08/10/2018 11:28 AM, Björn Töpel wrote:
> > > From: Björn Töpel <bjorn.topel@intel.com>
> > >
> > > This reverts commit 36e0f12bbfd3016f495904b35e41c5711707509f.
> > >
> > > The reverted commit adds a WARN to check against NULL entries in the
> > > mem_id_ht rhashtable. Any kernel path implementing the XDP (generic or
> > > driver) fast path is required to make a paired
> > > xdp_rxq_info_reg/xdp_rxq_info_unreg call for proper function. In
> > > addition, a driver using a different allocation scheme than the
> > > default MEM_TYPE_PAGE_SHARED is required to additionally call
> > > xdp_rxq_info_reg_mem_model.
> > >
> > > For MEM_TYPE_ZERO_COPY, an xdp_rxq_info_reg_mem_model call ensures
> > > that the mem_id_ht rhashtable has a properly inserted allocator id. If
> > > not, this would be a driver bug. A NULL pointer kernel OOPS is
> > > preferred to the WARN.
> > >
> > > Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > > Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> >
> > Given the last bpf pr went out yesterday night, I've applied this to
> > bpf-next (worst case we can just route it via stable), thanks!
>
> Ah, right! Thanks!
>
> bpf-next is OK. (Since this path is currently not used yet by any driver... :-()
Wasn't this dead code, anyway? The frame return path is for redirects,
and one can't convert_to_xdp_frame presently?
^ permalink raw reply
* Re: [PATCH bpf] Revert "xdp: add NULL pointer check in __xdp_return()"
From: Jakub Kicinski @ 2018-08-10 16:23 UTC (permalink / raw)
To: Björn Töpel
Cc: Jesper Dangaard Brouer, Alexei Starovoitov, Daniel Borkmann,
Netdev, Taehee Yoo, Björn Töpel, Karlsson, Magnus,
Magnus Karlsson, kafai
In-Reply-To: <CAJ+HfNi4k23Z6epy43wrEd-KTOU3W0NDTLMPCyUAjDNGRrrNQw@mail.gmail.com>
On Fri, 10 Aug 2018 17:15:07 +0200, Björn Töpel wrote:
> Den fre 10 aug. 2018 kl 12:18 skrev Jesper Dangaard Brouer <brouer@redhat.com>:
> >
> > On Fri, 10 Aug 2018 11:28:02 +0200
> > Björn Töpel <bjorn.topel@gmail.com> wrote:
> >
> > > From: Björn Töpel <bjorn.topel@intel.com>
> > >
> > > This reverts commit 36e0f12bbfd3016f495904b35e41c5711707509f.
> > >
> > > The reverted commit adds a WARN to check against NULL entries in the
> > > mem_id_ht rhashtable. Any kernel path implementing the XDP (generic or
> > > driver) fast path is required to make a paired
> > > xdp_rxq_info_reg/xdp_rxq_info_unreg call for proper function. In
> > > addition, a driver using a different allocation scheme than the
> > > default MEM_TYPE_PAGE_SHARED is required to additionally call
> > > xdp_rxq_info_reg_mem_model.
> > >
> > > For MEM_TYPE_ZERO_COPY, an xdp_rxq_info_reg_mem_model call ensures
> > > that the mem_id_ht rhashtable has a properly inserted allocator id. If
> > > not, this would be a driver bug. A NULL pointer kernel OOPS is
> > > preferred to the WARN.
> >
> > Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> >
> > As a comment says in the code: /* NB! Only valid from an xdp_buff! */
> > Which is (currently) guarded by the return/exit in convert_to_xdp_frame().
> >
> > This means that this code path can only be invoked while the driver is
> > still running under the RX NAPI process. Thus, there is no chance that
> > the allocator-id is gone (via calling xdp_rxq_info_unreg) for this code
> > path.
> >
> > But I really hope we at somepoint can convert a MEM_TYPE_ZERO_COPY into
> > a form of xdp_frame, that can travel further into the redirect-core.
> > In which case, we likely need to handle the NULL case (but also need
> > other code to handle what to do with the memory backing the frame)
> >
> > (I'm my vision here:)
> >
> > I really dislike that the current Zero-Copy mode steal ALL packets,
> > when ZC is enabled on a RX-queue. This is not better than the existing
> > bypass solutions, which have ugly ways of re-injecting packet back into
> > the network stack. With the integration with XDP, we have the
> > flexibility of selecting frames, that we don't want to be "bypassed"
> > into AF_XDP, and want the kernel process these. (The most common
> > use-case is letting the kernel handle the arptable). IHMO this is what
> > will/would make AF_XDP superior to other bypass solutions.
Perhaps I'm misunderstanding, but I don't think that's necessarily
true. AFAIU on XDP_PASS drivers should copy the frame into a skb and
pass it up the stack. Granted that's fairly slow but *semantically*
AF_XDP doesn't necessarily steal all the packets :)
> Thanks for putting your visions/ideas here! I agree with both of your
> last sections, and this is what we're working towards. AF_XDP ZC has
> to play nicer with XDP. The current (well, the soon-to-be-published
> [1] ;-)) ZC scheme is just a first step, and should be seen as a
> starting point so people can start playing using AF_XDP. Jakub also
> mentioned these issues a couple of threads ago, so there are
> definitely more people feeling the ZC allocator pains. Mid-term a
> sophisticated/proper and generic (for inter-driver reuse) ZC allocator
> is needed; Converting xdp_buffs to xdp_frames cheaply for multi-CPU
> completion, and hopefully dito for the XDP_PASS/kernel stack path. But
> let's start with something simple that works, and take it from there.
>
> Björn
>
> [1] WIP: https://github.com/bjoto/linux/tree/af-xdp-i40e-zc
Nice, looking forward to a refresh of i40e patches! :)
> > > Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > > Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> > > ---
> > > net/core/xdp.c | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/net/core/xdp.c b/net/core/xdp.c
> > > index 6771f1855b96..9d1f22072d5d 100644
> > > --- a/net/core/xdp.c
> > > +++ b/net/core/xdp.c
> > > @@ -345,8 +345,7 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> > > rcu_read_lock();
> > > /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
> > > xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
> > > - if (!WARN_ON_ONCE(!xa))
> > > - xa->zc_alloc->free(xa->zc_alloc, handle);
> > > + xa->zc_alloc->free(xa->zc_alloc, handle);
> > > rcu_read_unlock();
> > > default:
> > > /* Not possible, checked in xdp_rxq_info_reg_mem_model() */
> >
> >
> >
> > --
> > Best regards,
> > Jesper Dangaard Brouer
> > MSc.CS, Principal Kernel Engineer at Red Hat
> > LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH net-next 2/2] ip: process in-order fragments efficiently
From: Peter Oskolkov @ 2018-08-10 16:22 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Peter Oskolkov, Eric Dumazet, Cc : Florian Westphal
In-Reply-To: <20180810162246.46805-1-posk@google.com>
This patch changes the runtime behavior of IP defrag queue:
incoming in-order fragments are added to the end of the current
list/"run" of in-order fragments at the tail.
On some workloads, UDP stream performance is substantially improved:
RX: ./udp_stream -F 10 -T 2 -l 60
TX: ./udp_stream -c -H <host> -F 10 -T 5 -l 60
with this patchset applied on a 10Gbps receiver:
throughput=9524.18
throughput_units=Mbit/s
upstream (net-next):
throughput=4608.93
throughput_units=Mbit/s
Reported-by: Willem de Bruijn <willemb@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Cc: Florian Westphal <fw@strlen.de>
---
net/ipv4/inet_fragment.c | 2 +-
net/ipv4/ip_fragment.c | 110 ++++++++++++++++++++++++---------------
2 files changed, 70 insertions(+), 42 deletions(-)
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index 6d258a5669e7..bcb11f3a27c0 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -146,7 +146,7 @@ void inet_frag_destroy(struct inet_frag_queue *q)
fp = xp;
} while (fp);
} else {
- sum_truesize = skb_rbtree_purge(&q->rb_fragments);
+ sum_truesize = inet_frag_rbtree_purge(&q->rb_fragments);
}
sum = sum_truesize + f->qsize;
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 26ace9d2d976..88281fbce88c 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -126,8 +126,8 @@ static u8 ip4_frag_ecn(u8 tos)
static struct inet_frags ip4_frags;
-static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
- struct net_device *dev);
+static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
+ struct sk_buff *prev_tail, struct net_device *dev);
static void ip4_frag_init(struct inet_frag_queue *q, const void *a)
@@ -219,7 +219,12 @@ static void ip_expire(struct timer_list *t)
head = skb_rb_first(&qp->q.rb_fragments);
if (!head)
goto out;
- rb_erase(&head->rbnode, &qp->q.rb_fragments);
+ if (FRAG_CB(head)->next_frag)
+ rb_replace_node(&head->rbnode,
+ &FRAG_CB(head)->next_frag->rbnode,
+ &qp->q.rb_fragments);
+ else
+ rb_erase(&head->rbnode, &qp->q.rb_fragments);
memset(&head->rbnode, 0, sizeof(head->rbnode));
barrier();
}
@@ -320,7 +325,7 @@ static int ip_frag_reinit(struct ipq *qp)
return -ETIMEDOUT;
}
- sum_truesize = skb_rbtree_purge(&qp->q.rb_fragments);
+ sum_truesize = inet_frag_rbtree_purge(&qp->q.rb_fragments);
sub_frag_mem_limit(qp->q.net, sum_truesize);
qp->q.flags = 0;
@@ -329,6 +334,7 @@ static int ip_frag_reinit(struct ipq *qp)
qp->q.fragments = NULL;
qp->q.rb_fragments = RB_ROOT;
qp->q.fragments_tail = NULL;
+ qp->q.last_run_head = NULL;
qp->iif = 0;
qp->ecn = 0;
@@ -340,7 +346,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb)
{
struct net *net = container_of(qp->q.net, struct net, ipv4.frags);
struct rb_node **rbn, *parent;
- struct sk_buff *skb1;
+ struct sk_buff *skb1, *prev_tail;
struct net_device *dev;
unsigned int fragsize;
int flags, offset;
@@ -418,38 +424,41 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb)
*/
/* Find out where to put this fragment. */
- skb1 = qp->q.fragments_tail;
- if (!skb1) {
- /* This is the first fragment we've received. */
- rb_link_node(&skb->rbnode, NULL, &qp->q.rb_fragments.rb_node);
- qp->q.fragments_tail = skb;
- } else if ((skb1->ip_defrag_offset + skb1->len) < end) {
- /* This is the common/special case: skb goes to the end. */
+ prev_tail = qp->q.fragments_tail;
+ if (!prev_tail)
+ ip4_frag_create_run(&qp->q, skb); /* First fragment. */
+ else if (prev_tail->ip_defrag_offset + prev_tail->len < end) {
+ /* This is the common case: skb goes to the end. */
/* Detect and discard overlaps. */
- if (offset < (skb1->ip_defrag_offset + skb1->len))
+ if (offset < prev_tail->ip_defrag_offset + prev_tail->len)
goto discard_qp;
- /* Insert after skb1. */
- rb_link_node(&skb->rbnode, &skb1->rbnode, &skb1->rbnode.rb_right);
- qp->q.fragments_tail = skb;
+ if (offset == prev_tail->ip_defrag_offset + prev_tail->len)
+ ip4_frag_append_to_last_run(&qp->q, skb);
+ else
+ ip4_frag_create_run(&qp->q, skb);
} else {
- /* Binary search. Note that skb can become the first fragment, but
- * not the last (covered above). */
+ /* Binary search. Note that skb can become the first fragment,
+ * but not the last (covered above).
+ */
rbn = &qp->q.rb_fragments.rb_node;
do {
parent = *rbn;
skb1 = rb_to_skb(parent);
if (end <= skb1->ip_defrag_offset)
rbn = &parent->rb_left;
- else if (offset >= skb1->ip_defrag_offset + skb1->len)
+ else if (offset >= skb1->ip_defrag_offset +
+ FRAG_CB(skb1)->frag_run_len)
rbn = &parent->rb_right;
else /* Found an overlap with skb1. */
goto discard_qp;
} while (*rbn);
/* Here we have parent properly set, and rbn pointing to
- * one of its NULL left/right children. Insert skb. */
+ * one of its NULL left/right children. Insert skb.
+ */
+ ip4_frag_init_run(skb);
rb_link_node(&skb->rbnode, parent, rbn);
+ rb_insert_color(&skb->rbnode, &qp->q.rb_fragments);
}
- rb_insert_color(&skb->rbnode, &qp->q.rb_fragments);
if (dev)
qp->iif = dev->ifindex;
@@ -476,7 +485,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb)
unsigned long orefdst = skb->_skb_refdst;
skb->_skb_refdst = 0UL;
- err = ip_frag_reasm(qp, skb, dev);
+ err = ip_frag_reasm(qp, skb, prev_tail, dev);
skb->_skb_refdst = orefdst;
return err;
}
@@ -495,7 +504,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb)
/* Build a new IP datagram from all its fragments. */
static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
- struct net_device *dev)
+ struct sk_buff *prev_tail, struct net_device *dev)
{
struct net *net = container_of(qp->q.net, struct net, ipv4.frags);
struct iphdr *iph;
@@ -519,10 +528,16 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
fp = skb_clone(skb, GFP_ATOMIC);
if (!fp)
goto out_nomem;
- rb_replace_node(&skb->rbnode, &fp->rbnode, &qp->q.rb_fragments);
+ FRAG_CB(fp)->next_frag = FRAG_CB(skb)->next_frag;
+ if (RB_EMPTY_NODE(&skb->rbnode))
+ FRAG_CB(prev_tail)->next_frag = fp;
+ else
+ rb_replace_node(&skb->rbnode, &fp->rbnode,
+ &qp->q.rb_fragments);
if (qp->q.fragments_tail == skb)
qp->q.fragments_tail = fp;
skb_morph(skb, head);
+ FRAG_CB(skb)->next_frag = FRAG_CB(head)->next_frag;
rb_replace_node(&head->rbnode, &skb->rbnode,
&qp->q.rb_fragments);
consume_skb(head);
@@ -558,7 +573,7 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
for (i = 0; i < skb_shinfo(head)->nr_frags; i++)
plen += skb_frag_size(&skb_shinfo(head)->frags[i]);
clone->len = clone->data_len = head->data_len - plen;
- skb->truesize += clone->truesize;
+ head->truesize += clone->truesize;
clone->csum = 0;
clone->ip_summed = head->ip_summed;
add_frag_mem_limit(qp->q.net, clone->truesize);
@@ -571,24 +586,36 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
skb_push(head, head->data - skb_network_header(head));
/* Traverse the tree in order, to build frag_list. */
+ fp = FRAG_CB(head)->next_frag;
rbn = rb_next(&head->rbnode);
rb_erase(&head->rbnode, &qp->q.rb_fragments);
- while (rbn) {
- struct rb_node *rbnext = rb_next(rbn);
- fp = rb_to_skb(rbn);
- rb_erase(rbn, &qp->q.rb_fragments);
- rbn = rbnext;
- *nextp = fp;
- nextp = &fp->next;
- fp->prev = NULL;
- memset(&fp->rbnode, 0, sizeof(fp->rbnode));
- head->data_len += fp->len;
- head->len += fp->len;
- if (head->ip_summed != fp->ip_summed)
- head->ip_summed = CHECKSUM_NONE;
- else if (head->ip_summed == CHECKSUM_COMPLETE)
- head->csum = csum_add(head->csum, fp->csum);
- head->truesize += fp->truesize;
+ while (rbn || fp) {
+ /* fp points to the next sk_buff in the current run;
+ * rbn points to the next run.
+ */
+ /* Go through the current run. */
+ while (fp) {
+ *nextp = fp;
+ nextp = &fp->next;
+ fp->prev = NULL;
+ memset(&fp->rbnode, 0, sizeof(fp->rbnode));
+ head->data_len += fp->len;
+ head->len += fp->len;
+ if (head->ip_summed != fp->ip_summed)
+ head->ip_summed = CHECKSUM_NONE;
+ else if (head->ip_summed == CHECKSUM_COMPLETE)
+ head->csum = csum_add(head->csum, fp->csum);
+ head->truesize += fp->truesize;
+ fp = FRAG_CB(fp)->next_frag;
+ }
+ /* Move to the next run. */
+ if (rbn) {
+ struct rb_node *rbnext = rb_next(rbn);
+
+ fp = rb_to_skb(rbn);
+ rb_erase(rbn, &qp->q.rb_fragments);
+ rbn = rbnext;
+ }
}
sub_frag_mem_limit(qp->q.net, head->truesize);
@@ -624,6 +651,7 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *skb,
qp->q.fragments = NULL;
qp->q.rb_fragments = RB_ROOT;
qp->q.fragments_tail = NULL;
+ qp->q.last_run_head = NULL;
return 0;
out_nomem:
--
2.18.0.597.ga71716f1ad-goog
^ permalink raw reply related
* [PATCH net-next 1/2] ip: add helpers to process in-order fragments faster.
From: Peter Oskolkov @ 2018-08-10 16:22 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Peter Oskolkov, Eric Dumazet, Cc : Florian Westphal
This patch introduces several helper functions/macros that will be
used in the follow-up patch. No runtime changes yet.
The new logic (fully implemented in the second patch) is as follows:
* Nodes in the rb-tree will now contain not single fragments, but lists
of consecutive fragments ("runs").
* At each point in time, the current "active" run at the tail is
maintained/tracked. Fragments that arrive in-order, adjacent
to the previous tail fragment, are added to this tail run without
triggering the re-balancing of the rb-tree.
* If a fragment arrives out of order with the offset _before_ the tail run,
it is inserted into the rb-tree as a single fragment.
* If a fragment arrives after the current tail fragment (with a gap),
it starts a new "tail" run, as is inserted into the rb-tree
at the end as the head of the new run.
skb->cb is used to store additional information
needed here (suggested by Eric Dumazet).
Reported-by: Willem de Bruijn <willemb@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Cc: Florian Westphal <fw@strlen.de>
---
include/net/inet_frag.h | 6 ++++
net/ipv4/ip_fragment.c | 73 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 79 insertions(+)
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index b86d14528188..1662cbc0b46b 100644
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -57,7 +57,9 @@ struct frag_v6_compare_key {
* @lock: spinlock protecting this frag
* @refcnt: reference count of the queue
* @fragments: received fragments head
+ * @rb_fragments: received fragments rb-tree root
* @fragments_tail: received fragments tail
+ * @last_run_head: the head of the last "run". see ip_fragment.c
* @stamp: timestamp of the last received fragment
* @len: total length of the original datagram
* @meat: length of received fragments so far
@@ -78,6 +80,7 @@ struct inet_frag_queue {
struct sk_buff *fragments; /* Used in IPv6. */
struct rb_root rb_fragments; /* Used in IPv4. */
struct sk_buff *fragments_tail;
+ struct sk_buff *last_run_head;
ktime_t stamp;
int len;
int meat;
@@ -113,6 +116,9 @@ void inet_frag_kill(struct inet_frag_queue *q);
void inet_frag_destroy(struct inet_frag_queue *q);
struct inet_frag_queue *inet_frag_find(struct netns_frags *nf, void *key);
+/* Free all skbs in the queue; return the sum of their truesizes. */
+unsigned int inet_frag_rbtree_purge(struct rb_root *root);
+
static inline void inet_frag_put(struct inet_frag_queue *q)
{
if (refcount_dec_and_test(&q->refcnt))
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 7cb7ed761d8c..26ace9d2d976 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -57,6 +57,57 @@
*/
static const char ip_frag_cache_name[] = "ip4-frags";
+/* Use skb->cb to track consecutive/adjacent fragments coming at
+ * the end of the queue. Nodes in the rb-tree queue will
+ * contain "runs" of one or more adjacent fragments.
+ *
+ * Invariants:
+ * - next_frag is NULL at the tail of a "run";
+ * - the head of a "run" has the sum of all fragment lengths in frag_run_len.
+ */
+struct ipfrag_skb_cb {
+ struct inet_skb_parm h;
+ struct sk_buff *next_frag;
+ int frag_run_len;
+};
+
+#define FRAG_CB(skb) ((struct ipfrag_skb_cb *)((skb)->cb))
+
+static void ip4_frag_init_run(struct sk_buff *skb)
+{
+ BUILD_BUG_ON(sizeof(struct ipfrag_skb_cb) > sizeof(skb->cb));
+
+ FRAG_CB(skb)->next_frag = NULL;
+ FRAG_CB(skb)->frag_run_len = skb->len;
+}
+
+/* Append skb to the last "run". */
+static void ip4_frag_append_to_last_run(struct inet_frag_queue *q,
+ struct sk_buff *skb)
+{
+ RB_CLEAR_NODE(&skb->rbnode);
+ FRAG_CB(skb)->next_frag = NULL;
+
+ FRAG_CB(q->last_run_head)->frag_run_len += skb->len;
+ FRAG_CB(q->fragments_tail)->next_frag = skb;
+ q->fragments_tail = skb;
+}
+
+/* Create a new "run" with the skb. */
+static void ip4_frag_create_run(struct inet_frag_queue *q, struct sk_buff *skb)
+{
+ if (q->last_run_head)
+ rb_link_node(&skb->rbnode, &q->last_run_head->rbnode,
+ &q->last_run_head->rbnode.rb_right);
+ else
+ rb_link_node(&skb->rbnode, NULL, &q->rb_fragments.rb_node);
+ rb_insert_color(&skb->rbnode, &q->rb_fragments);
+
+ ip4_frag_init_run(skb);
+ q->fragments_tail = skb;
+ q->last_run_head = skb;
+}
+
/* Describe an entry in the "incomplete datagrams" queue. */
struct ipq {
struct inet_frag_queue q;
@@ -654,6 +705,28 @@ struct sk_buff *ip_check_defrag(struct net *net, struct sk_buff *skb, u32 user)
}
EXPORT_SYMBOL(ip_check_defrag);
+unsigned int inet_frag_rbtree_purge(struct rb_root *root)
+{
+ struct rb_node *p = rb_first(root);
+ unsigned int sum = 0;
+
+ while (p) {
+ struct sk_buff *skb = rb_entry(p, struct sk_buff, rbnode);
+
+ p = rb_next(p);
+ rb_erase(&skb->rbnode, root);
+ while (skb) {
+ struct sk_buff *next = FRAG_CB(skb)->next_frag;
+
+ sum += skb->truesize;
+ kfree_skb(skb);
+ skb = next;
+ }
+ }
+ return sum;
+}
+EXPORT_SYMBOL(inet_frag_rbtree_purge);
+
#ifdef CONFIG_SYSCTL
static int dist_min;
--
2.18.0.597.ga71716f1ad-goog
^ permalink raw reply related
* Re: [PATCH v2 14/29] net: simplify eth_platform_get_mac_address()
From: Bartosz Golaszewski @ 2018-08-10 16:17 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <CAHp75Ve28aNe+FCK3p4OLsDf7dNo-iJ1VR=pyx+Y9OUn3sjYBw@mail.gmail.com>
2018-08-10 16:39 GMT+02:00 Andy Shevchenko <andy.shevchenko@gmail.com>:
> On Fri, Aug 10, 2018 at 11:05 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> We don't need to use pci_device_to_OF_node() - we can retrieve
>> dev->of_node directly even for pci devices.
>>
>
>> struct device_node *dp;
>>
>> - if (dev_is_pci(dev))
>> - dp = pci_device_to_OF_node(to_pci_dev(dev));
>> - else
>> - dp = dev->of_node;
>> -
>> + dp = dev->of_node;
>> addr = NULL;
>> if (dp)
>> addr = of_get_mac_address(dp);
>
> Looking more at this I could even propose to change all above by
>
> addr = device_get_mac_address(dev, mac_addr, ETH_ALEN);
>
> Thoughts?
>
> --
> With Best Regards,
> Andy Shevchenko
Indeed seems like it's even more generalized. Thanks for spotting that.
Bart
^ permalink raw reply
* Motorcycle Owners List
From: Brenda Calkins @ 2018-08-10 14:51 UTC (permalink / raw)
To: netdev
--
Hi,
Greetings of the day!
Would you be interested in acquiring an email list of "Motorcycle Owners List" from USA?
We also have data for Luxury Car Owners List, Luxury Brand Buyers List, Mercedes-Benz Owners, BMW Owners, Audi Owners, Hyundai Owners, Porsche Owners, Toyota Owners, Harley Davidson Owners List, Car Owners, HNI list, RV Owners and many more...
All the contacts are opt-in verified, 100% permission based and can be used for unlimited multi-channel marketing.
Please let me know your thoughts towards procuring the Motorcycle Owners List.
Best Regards,
Brenda Calkins
Research Analyst
We respect your privacy, if you do not wish to receive any further emails from our end, please reply with a subject “Leave Out”.
^ permalink raw reply
* Re: [PATCH net] l2tp: use sk_dst_check() to avoid race on sk->sk_dst_cache
From: Guillaume Nault @ 2018-08-10 15:59 UTC (permalink / raw)
To: Wei Wang; +Cc: David Miller, netdev, Martin KaFai Lau, David Ahern, Cong Wang
In-Reply-To: <20180809185405.38744-1-tracywwnj@gmail.com>
On Thu, Aug 09, 2018 at 11:54:05AM -0700, Wei Wang wrote:
> From: Wei Wang <weiwan@google.com>
>
> In l2tp code, if it is a L2TP_UDP_ENCAP tunnel, tunnel->sk points to a
> UDP socket. User could call sendmsg() on both this tunnel and the UDP
> socket itself concurrently. As l2tp_xmit_skb() holds socket lock and call
> __sk_dst_check() to refresh sk->sk_dst_cache, while udpv6_sendmsg() is
> lockless and call sk_dst_check() to refresh sk->sk_dst_cache, there
> could be a race and cause the dst cache to be freed multiple times.
> So we fix l2tp side code to always call sk_dst_check() to garantee
> xchg() is called when refreshing sk->sk_dst_cache to avoid race
> conditions.
>
> Syzkaller reported stack trace:
> BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
> BUG: KASAN: use-after-free in atomic_fetch_add_unless include/linux/atomic.h:575 [inline]
> BUG: KASAN: use-after-free in atomic_add_unless include/linux/atomic.h:597 [inline]
> BUG: KASAN: use-after-free in dst_hold_safe include/net/dst.h:308 [inline]
> BUG: KASAN: use-after-free in ip6_hold_safe+0xe6/0x670 net/ipv6/route.c:1029
> Read of size 4 at addr ffff8801aea9a880 by task syz-executor129/4829
>
> CPU: 0 PID: 4829 Comm: syz-executor129 Not tainted 4.18.0-rc7-next-20180802+ #30
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
> check_memory_region_inline mm/kasan/kasan.c:260 [inline]
> check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
> kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
> atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
> atomic_fetch_add_unless include/linux/atomic.h:575 [inline]
> atomic_add_unless include/linux/atomic.h:597 [inline]
> dst_hold_safe include/net/dst.h:308 [inline]
> ip6_hold_safe+0xe6/0x670 net/ipv6/route.c:1029
> rt6_get_pcpu_route net/ipv6/route.c:1249 [inline]
> ip6_pol_route+0x354/0xd20 net/ipv6/route.c:1922
> ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:2098
> fib6_rule_lookup+0x283/0x890 net/ipv6/fib6_rules.c:122
> ip6_route_output_flags+0x2c5/0x350 net/ipv6/route.c:2126
> ip6_dst_lookup_tail+0x1278/0x1da0 net/ipv6/ip6_output.c:978
> ip6_dst_lookup_flow+0xc8/0x270 net/ipv6/ip6_output.c:1079
> ip6_sk_dst_lookup_flow+0x5ed/0xc50 net/ipv6/ip6_output.c:1117
> udpv6_sendmsg+0x2163/0x36b0 net/ipv6/udp.c:1354
> inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:622 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:632
> ___sys_sendmsg+0x51d/0x930 net/socket.c:2115
> __sys_sendmmsg+0x240/0x6f0 net/socket.c:2210
> __do_sys_sendmmsg net/socket.c:2239 [inline]
> __se_sys_sendmmsg net/socket.c:2236 [inline]
> __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2236
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x446a29
> Code: e8 ac b8 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f4de5532db8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
> RAX: ffffffffffffffda RBX: 00000000006dcc38 RCX: 0000000000446a29
> RDX: 00000000000000b8 RSI: 0000000020001b00 RDI: 0000000000000003
> RBP: 00000000006dcc30 R08: 00007f4de5533700 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dcc3c
> R13: 00007ffe2b830fdf R14: 00007f4de55339c0 R15: 0000000000000001
>
> Fixes: 71b1391a4128 ("l2tp: ensure sk->dst is still valid")
> Reported-by: syzbot+05f840f3b04f211bad55@syzkaller.appspotmail.com
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> Cc: David Ahern <dsahern@gmail.com>
> Cc: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> net/l2tp/l2tp_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> index 40261cb68e83..7166b61338d4 100644
> --- a/net/l2tp/l2tp_core.c
> +++ b/net/l2tp/l2tp_core.c
> @@ -1110,7 +1110,7 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
>
> /* Get routing info from the tunnel socket */
> skb_dst_drop(skb);
> - skb_dst_set(skb, dst_clone(__sk_dst_check(sk, 0)));
> + skb_dst_set(skb, dst_clone(sk_dst_check(sk, 0)));
>
With sk_dst_check(), we're now holding an extra reference on the cached
dst. How is it dropped? Shouldn't we remove dst_clone()?
Also, does syzbot have a reproducer? I haven't found the original
report on the mailing list.
^ permalink raw reply
* [PATCH v2] Add icmp_echo_ignore_all support for ICMPv6
From: Virgile Jarry @ 2018-08-10 15:48 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev,
linux-kernel
Preventing the kernel from responding to ICMP Echo Requests messages
can be useful in several ways. The sysctl parameter
'icmp_echo_ignore_all' can be used to prevent the kernel from
responding to IPv4 ICMP echo requests. For IPv6 pings, such
a sysctl kernel parameter did not exist.
Add the ability to prevent the kernel from responding to IPv6
ICMP echo requests through the use of the following sysctl
parameter : /proc/sys/net/ipv6/icmp/echo_ignore_all.
Update the documentation to reflect this change.
Signed-off-by: Virgile Jarry <virgile@acceis.fr>
---
Changes in v2:
- Added support for sysctl interface (and not just /proc filesystem)
Documentation/networking/ip-sysctl.txt | 5 +++++
include/net/netns/ipv6.h | 1 +
include/uapi/linux/sysctl.h | 3 ++-
net/ipv6/af_inet6.c | 1 +
net/ipv6/icmp.c | 16 +++++++++++++---
5 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index ce8fbf5..5042a13 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1863,6 +1863,11 @@ ratelimit - INTEGER
otherwise the minimal space between responses in milliseconds.
Default: 1000
+echo_ignore_all - BOOLEAN
+ If set non-zero, then the kernel will ignore all ICMP ECHO
+ requests sent to it over the IPv6 protocol.
+ Default: 0
+
xfrm6_gc_thresh - INTEGER
The threshold at which we will start garbage collecting for IPv6
destination cache entries. At twice this value the system will
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index 762ac99..f0e396a 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -32,6 +32,7 @@ struct netns_sysctl_ipv6 {
int flowlabel_consistency;
int auto_flowlabels;
int icmpv6_time;
+ int icmpv6_echo_ignore_all;
int anycast_src_echo_reply;
int ip_nonlocal_bind;
int fwmark_reflect;
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 6b58371..d71013f 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -575,7 +575,8 @@ enum {
/* /proc/sys/net/ipv6/icmp */
enum {
- NET_IPV6_ICMP_RATELIMIT=1
+ NET_IPV6_ICMP_RATELIMIT = 1,
+ NET_IPV6_ICMP_ECHO_IGNORE_ALL = 2
};
/* /proc/sys/net/<protocol>/neigh/<dev> */
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 9ed0eae..d0033b3 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -833,6 +833,7 @@ static int __net_init inet6_net_init(struct net *net)
net->ipv6.sysctl.bindv6only = 0;
net->ipv6.sysctl.icmpv6_time = 1*HZ;
+ net->ipv6.sysctl.icmpv6_echo_ignore_all = 0;
net->ipv6.sysctl.flowlabel_consistency = 1;
net->ipv6.sysctl.auto_flowlabels = IP6_DEFAULT_AUTO_FLOW_LABELS;
net->ipv6.sysctl.idgen_retries = 3;
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index ef2505a..1d869f1 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -800,6 +800,7 @@ void icmpv6_notify(struct sk_buff *skb, u8 type, u8 code, __be32 info)
static int icmpv6_rcv(struct sk_buff *skb)
{
+ struct net *net = dev_net(skb->dev);
struct net_device *dev = skb->dev;
struct inet6_dev *idev = __in6_dev_get(dev);
const struct in6_addr *saddr, *daddr;
@@ -849,7 +850,8 @@ static int icmpv6_rcv(struct sk_buff *skb)
switch (type) {
case ICMPV6_ECHO_REQUEST:
- icmpv6_echo_reply(skb);
+ if (!net->ipv6.sysctl.icmpv6_echo_ignore_all)
+ icmpv6_echo_reply(skb);
break;
case ICMPV6_ECHO_REPLY:
@@ -1110,6 +1112,13 @@ static struct ctl_table ipv6_icmp_table_template[] = {
.mode = 0644,
.proc_handler = proc_dointvec_ms_jiffies,
},
+ {
+ .procname = "echo_ignore_all",
+ .data = &init_net.ipv6.sysctl.icmpv6_echo_ignore_all,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
{ },
};
@@ -1121,9 +1130,10 @@ struct ctl_table * __net_init ipv6_icmp_sysctl_init(struct net *net)
sizeof(ipv6_icmp_table_template),
GFP_KERNEL);
- if (table)
+ if (table) {
table[0].data = &net->ipv6.sysctl.icmpv6_time;
-
+ table[1].data = &net->ipv6.sysctl.icmpv6_echo_ignore_all;
+ }
return table;
}
#endif
--
2.7.4
^ permalink raw reply related
* Re: Error running AF_XDP sample application
From: Björn Töpel @ 2018-08-10 15:45 UTC (permalink / raw)
To: kdjimeli; +Cc: Jakub Kicinski, Netdev, netdev-owner
In-Reply-To: <9a31684912d059772cfbb8e2062c38af@igalia.com>
Den fre 10 aug. 2018 kl 15:23 skrev Konrad Djimeli <kdjimeli@igalia.com>:
>
> On 2018-08-10 11:58, Konrad Djimeli wrote:
> > On 2018-08-10 03:51, Jakub Kicinski wrote:
> >> On Thu, 09 Aug 2018 18:18:08 +0200, kdjimeli wrote:
> >>> Hello,
> >>>
> >>> I have been trying to test a sample AF_XDP program, but I have been
> >>> experiencing some issues.
> >>> After building the sample code
> >>> https://github.com/torvalds/linux/tree/master/samples/bpf,
> >>> when running the xdpsock binary, I get the errors
> >>> "libbpf: failed to create map (name: 'xsks_map'): Invalid argument"
> >>> "libbpf: failed to load object './xdpsock_kern.o"
> >>>
> >>> I tried to figure out the cause of the error but all I know is that it
> >>> occurs at line 910 with the function
> >>> call "bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd)".
> >>>
> >>> Please I would like to inquire what could be a possible for this error.
> >>
> >> which kernel version are you running?
> >
> > My kernel version is 4.18.0-rc8+. I cloned it from
> > https://github.com/torvalds/linux before building a running.
> >
> > My commit head(git show-ref --head) is at
> > 1236568ee3cbb0d3ac62d0074a29b97ecf34cbbc HEAD
> > 1236568ee3cbb0d3ac62d0074a29b97ecf34cbbc refs/heads/master
> > 1236568ee3cbb0d3ac62d0074a29b97ecf34cbbc refs/remotes/origin/HEAD
> > 1236568ee3cbb0d3ac62d0074a29b97ecf34cbbc refs/remotes/origin/master
> > ...
> >
> >
> > I also applied the patch https://patchwork.ozlabs.org/patch/949884/
> > (samples: bpf: convert xdpsock_user.c to libbpf ), as the error was
> > initially in the form show below:
> > "failed to create a map: 22 Invalid argument"
> > "ERROR: load_bpf_file"
> >
> > Thanks
> > Konrad
>
> Also other sample applications that make use of other bpf maps, such as
> BPF_MAP_TYPE_CPUMAP in xdp_redirect_cpu work fine. But the application
> with BPF_MAP_TYPE_XSKMAP fails producing the error mentioned above.
>
> Thanks
> Konrad
Thanks for taking AF_XDP for a spin!
Before I start digging into details; Do you have CONFIG_XDP_SOCKETS=y
in your config? :-)
Björn
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: core: remove unnecessary function mlxsw_core_driver_put
From: Ido Schimmel @ 2018-08-10 15:26 UTC (permalink / raw)
To: YueHaibing; +Cc: davem, jiri, linux-kernel, netdev
In-Reply-To: <20180810023730.13140-1-yuehaibing@huawei.com>
On Fri, Aug 10, 2018 at 10:37:30AM +0800, YueHaibing wrote:
> The function mlxsw_core_driver_put only traverse mlxsw_core_driver_list
> to find the matched mlxsw_driver,but never used it.
> So it can be removed safely.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
FWIW, this function used to call module_put(), but it was removed in
commit 1d20d23c59c9 ("mlxsw: Move PCI id table definitions into driver
modules").
Thanks!
^ permalink raw reply
* Re: [PATCH 0/2] net: ethernet: ti: cpsw: fix runtime pm while add/del reserved vid
From: Grygorii Strashko @ 2018-08-10 17:53 UTC (permalink / raw)
To: Ivan Khoronzhuk, davem; +Cc: linux-omap, netdev, linux-kernel
In-Reply-To: <20180810124709.25089-1-ivan.khoronzhuk@linaro.org>
On 08/10/2018 07:47 AM, Ivan Khoronzhuk wrote:
> Here 2 not critical fixes for:
> - vlan ale table leak while error if deleting vlan (simplifies next fix)
> - runtime pm while try to set reserved vlan
>
> Based on net/master
>
> Ivan Khoronzhuk (2):
> net: ethernet: ti: cpsw: clear all entries when delete vid
> net: ethernet: ti: cpsw: fix runtime_pm while add/kill vlan
>
> drivers/net/ethernet/ti/cpsw.c | 25 +++++++++++--------------
> drivers/net/ethernet/ti/cpsw_ale.c | 2 +-
> 2 files changed, 12 insertions(+), 15 deletions(-)
>
Thank you.
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH bpf-next 0/4] Convert filter.txt to RST
From: Alexei Starovoitov @ 2018-08-10 17:51 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Daniel Borkmann, Alexei Starovoitov,
David S. Miller, Kees Cook, Andy Lutomirski, Will Drewry,
linux-doc, Network Development, LKML
In-Reply-To: <20180810065752.2ab5473d@lwn.net>
On Fri, Aug 10, 2018 at 5:57 AM Jonathan Corbet <corbet@lwn.net> wrote:
>
> The objective actually is to have SPDX tags in all files in the kernel.
> That includes documentation, even though people, as always, care less
> about the docs than they do the code.
right, but let's do that as a separate patch set.
In the current set I'd focus on reviewing the actual doc changes.
In particular completely removing
Documentation/networking/filter.txt
feels wrong, since lots of websites point directly there.
Can we have at least few words there pointing to new location?
^ permalink raw reply
* Re: C45 support and mdiobus_scan
From: Tom Lendacky @ 2018-08-10 15:20 UTC (permalink / raw)
To: Andrew Lunn, Jose Abreu; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180809152502.GC20006@lunn.ch>
On 8/9/2018 10:25 AM, Andrew Lunn wrote:
>>> The PCIe core will look in the device tree and when it creates the
>>> platform device for the i210 on the pcie bus, it points
>>> pdev->dev.of_node at this node. So long as you are using a platform
>>> with DT, you can do this. I hope you are not using x86..
>>
>> Yes I am :( Any possible solution for this?
I haven't looked too closely, but maybe you can add a new mdiobus_scan
function for 10G that attempts get_phy_device() with is_c45 set to true
and if nothing is found falls back to get_phy_device() with is_c45 set to
false. I don't know what would happen if you have a non-c45 phy attached,
but it's worth a shot to try it and see for each situation.
Thanks,
Tom
>
> Well, DT can be used with x86. I think Edison did that. But i assume
> your PCIe host is in ACPI, not DT. So getting this linking working
> will not be easy.
>
> There has been some work to add an ACPI binding for PHYs. I don't know
> if it actually got far enough that you can hack your DSDT to add a
> PHY. But i'm sure it did not get far enough that you can describe an
> MDIO bus in DSDT, so it probably is not going to help you.
>
>> I guess in ultimate case I will have to switch to ARM based setup.
>
> Yes, or MIPS.
>
> Andrew
>
^ permalink raw reply
* Re: [PATCH bpf] Revert "xdp: add NULL pointer check in __xdp_return()"
From: Björn Töpel @ 2018-08-10 15:16 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Netdev, Taehee Yoo, Jesper Dangaard Brouer,
Björn Töpel, Karlsson, Magnus, Magnus Karlsson, kafai
In-Reply-To: <5d07c5ce-2dea-7ab2-f5cf-7ed22d5da783@iogearbox.net>
Den fre 10 aug. 2018 kl 16:10 skrev Daniel Borkmann <daniel@iogearbox.net>:
>
> On 08/10/2018 11:28 AM, Björn Töpel wrote:
> > From: Björn Töpel <bjorn.topel@intel.com>
> >
> > This reverts commit 36e0f12bbfd3016f495904b35e41c5711707509f.
> >
> > The reverted commit adds a WARN to check against NULL entries in the
> > mem_id_ht rhashtable. Any kernel path implementing the XDP (generic or
> > driver) fast path is required to make a paired
> > xdp_rxq_info_reg/xdp_rxq_info_unreg call for proper function. In
> > addition, a driver using a different allocation scheme than the
> > default MEM_TYPE_PAGE_SHARED is required to additionally call
> > xdp_rxq_info_reg_mem_model.
> >
> > For MEM_TYPE_ZERO_COPY, an xdp_rxq_info_reg_mem_model call ensures
> > that the mem_id_ht rhashtable has a properly inserted allocator id. If
> > not, this would be a driver bug. A NULL pointer kernel OOPS is
> > preferred to the WARN.
> >
> > Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
>
> Given the last bpf pr went out yesterday night, I've applied this to
> bpf-next (worst case we can just route it via stable), thanks!
Ah, right! Thanks!
bpf-next is OK. (Since this path is currently not used yet by any driver... :-()
Björn
^ permalink raw reply
* Re: [PATCH bpf] Revert "xdp: add NULL pointer check in __xdp_return()"
From: Björn Töpel @ 2018-08-10 15:15 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexei Starovoitov, Daniel Borkmann, Netdev, Taehee Yoo,
Björn Töpel, Karlsson, Magnus, Magnus Karlsson, kafai,
Jakub Kicinski
In-Reply-To: <20180810121804.22aec831@redhat.com>
Den fre 10 aug. 2018 kl 12:18 skrev Jesper Dangaard Brouer <brouer@redhat.com>:
>
> On Fri, 10 Aug 2018 11:28:02 +0200
> Björn Töpel <bjorn.topel@gmail.com> wrote:
>
> > From: Björn Töpel <bjorn.topel@intel.com>
> >
> > This reverts commit 36e0f12bbfd3016f495904b35e41c5711707509f.
> >
> > The reverted commit adds a WARN to check against NULL entries in the
> > mem_id_ht rhashtable. Any kernel path implementing the XDP (generic or
> > driver) fast path is required to make a paired
> > xdp_rxq_info_reg/xdp_rxq_info_unreg call for proper function. In
> > addition, a driver using a different allocation scheme than the
> > default MEM_TYPE_PAGE_SHARED is required to additionally call
> > xdp_rxq_info_reg_mem_model.
> >
> > For MEM_TYPE_ZERO_COPY, an xdp_rxq_info_reg_mem_model call ensures
> > that the mem_id_ht rhashtable has a properly inserted allocator id. If
> > not, this would be a driver bug. A NULL pointer kernel OOPS is
> > preferred to the WARN.
>
> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
>
> As a comment says in the code: /* NB! Only valid from an xdp_buff! */
> Which is (currently) guarded by the return/exit in convert_to_xdp_frame().
>
> This means that this code path can only be invoked while the driver is
> still running under the RX NAPI process. Thus, there is no chance that
> the allocator-id is gone (via calling xdp_rxq_info_unreg) for this code
> path.
>
> But I really hope we at somepoint can convert a MEM_TYPE_ZERO_COPY into
> a form of xdp_frame, that can travel further into the redirect-core.
> In which case, we likely need to handle the NULL case (but also need
> other code to handle what to do with the memory backing the frame)
>
> (I'm my vision here:)
>
> I really dislike that the current Zero-Copy mode steal ALL packets,
> when ZC is enabled on a RX-queue. This is not better than the existing
> bypass solutions, which have ugly ways of re-injecting packet back into
> the network stack. With the integration with XDP, we have the
> flexibility of selecting frames, that we don't want to be "bypassed"
> into AF_XDP, and want the kernel process these. (The most common
> use-case is letting the kernel handle the arptable). IHMO this is what
> will/would make AF_XDP superior to other bypass solutions.
>
>
Thanks for putting your visions/ideas here! I agree with both of your
last sections, and this is what we're working towards. AF_XDP ZC has
to play nicer with XDP. The current (well, the soon-to-be-published
[1] ;-)) ZC scheme is just a first step, and should be seen as a
starting point so people can start playing using AF_XDP. Jakub also
mentioned these issues a couple of threads ago, so there are
definitely more people feeling the ZC allocator pains. Mid-term a
sophisticated/proper and generic (for inter-driver reuse) ZC allocator
is needed; Converting xdp_buffs to xdp_frames cheaply for multi-CPU
completion, and hopefully dito for the XDP_PASS/kernel stack path. But
let's start with something simple that works, and take it from there.
Björn
[1] WIP: https://github.com/bjoto/linux/tree/af-xdp-i40e-zc
> > Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> > ---
> > net/core/xdp.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/net/core/xdp.c b/net/core/xdp.c
> > index 6771f1855b96..9d1f22072d5d 100644
> > --- a/net/core/xdp.c
> > +++ b/net/core/xdp.c
> > @@ -345,8 +345,7 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> > rcu_read_lock();
> > /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
> > xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
> > - if (!WARN_ON_ONCE(!xa))
> > - xa->zc_alloc->free(xa->zc_alloc, handle);
> > + xa->zc_alloc->free(xa->zc_alloc, handle);
> > rcu_read_unlock();
> > default:
> > /* Not possible, checked in xdp_rxq_info_reg_mem_model() */
>
>
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] net: chelsio: cxgb2: remove unused array pci_speed
From: David Miller @ 2018-08-10 17:25 UTC (permalink / raw)
To: colin.king; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180810080217.26758-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 10 Aug 2018 09:02:17 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Array pci_speed is defined but is never used hence it is redundant
> and can be removed.
>
> Cleans up clang warning:
> warning: 'pci_speed' defined but not used [-Wunused-const-variable=]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] mlxsw: remove unused arrays mlxsw_i2c_driver_name and mlxsw_pci_driver_name
From: David Miller @ 2018-08-10 17:25 UTC (permalink / raw)
To: colin.king; +Cc: jiri, idosch, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180810075328.26400-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 10 Aug 2018 08:53:28 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Arrays mlxsw_i2c_driver_name and mlxsw_pci_driver_name are defined
> but never used hence they are redundant and can be removed.
>
> Cleans up clang warnings:
> warning: 'mlxsw_i2c_driver_name' defined but not used
> warning: 'mlxsw_pci_driver_name' defined but not used
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Provide stub for __netif_set_xps_queue if there is no CONFIG_XPS
From: David Miller @ 2018-08-10 17:22 UTC (permalink / raw)
To: krzk; +Cc: netdev, linux-kernel, avagin
In-Reply-To: <1533890863-32341-1-git-send-email-krzk@kernel.org>
From: Krzysztof Kozlowski <krzk@kernel.org>
Date: Fri, 10 Aug 2018 10:47:43 +0200
> Building virtio_net driver without CONFIG_XPS fails with:
>
> drivers/net/virtio_net.c: In function ‘virtnet_set_affinity’:
> drivers/net/virtio_net.c:1910:3: error: implicit declaration of function ‘__netif_set_xps_queue’ [-Werror=implicit-function-declaration]
> __netif_set_xps_queue(vi->dev, mask, i, false);
> ^
> Fixes: 4d99f6602cb5 ("net: allow to call netif_reset_xps_queues() under cpus_read_lock")
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH iproute2/net-next v2] tc_util: Add support for showing TCA_STATS_BASIC_HW statistics
From: Eelco Chaudron @ 2018-08-10 14:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem
In-Reply-To: <20180810074454.4af9e5cd@xeon-e3>
On 10 Aug 2018, at 16:44, Stephen Hemminger wrote:
> On Fri, 10 Aug 2018 07:59:30 -0400
> Eelco Chaudron <echaudro@redhat.com> wrote:
>
>> + if (bs.bytes >= bs_hw.bytes && bs.packets >= bs_hw.packets) {
>> + print_string(PRINT_FP, NULL, "%s", _SL_);
>> + print_string(PRINT_FP, NULL, "%s", prefix);
>> + print_lluint(PRINT_ANY, "sw_bytes",
>> + "Sent software %llu bytes",
>> + bs.bytes - bs_hw.bytes);
>> + print_uint(PRINT_ANY, "sw_packets", " %u pkt",
>> + bs.packets - bs_hw.packets);
>> + }
>> + }
>> +
>> + print_string(PRINT_FP, NULL, "%s", _SL_);
>> + print_string(PRINT_FP, NULL, "%s", prefix);
>> + print_lluint(PRINT_ANY, "hw_bytes", "Sent hardware %llu bytes",
>> + bs_hw.bytes);
>
> What does the output look like?
See the two +’es below:
$ tc -s filter show dev enp3s0np0 parent ffff:
filter protocol ip pref 1 flower chain 0
filter protocol ip pref 1 flower chain 0 handle 0x1
eth_type ipv4
dst_ip 2.0.0.0
src_ip 1.0.0.0
ip_flags nofrag
in_hw
action order 1: mirred (Egress Redirect to device eth1) stolen
index 1 ref 1 bind 1 installed 0 sec used 0 sec
Action statistics:
Sent 534884742 bytes 8915697 pkt (dropped 0, overlimits 0 requeues 0)
+ Sent software 187542 bytes 4077 pkt
+ Sent hardware 534697200 bytes 8911620 pkt
backlog 0b 0p requeues 0
cookie 89173e6a44447001becfd486bda17e29
^ permalink raw reply
* Re: [PATCH iproute2/net-next v2] tc_util: Add support for showing TCA_STATS_BASIC_HW statistics
From: Stephen Hemminger @ 2018-08-10 14:44 UTC (permalink / raw)
To: Eelco Chaudron; +Cc: netdev, davem
In-Reply-To: <20180810115846.15762.3693.stgit@wsfd-netdev20.ntdv.lab.eng.bos.redhat.com>
On Fri, 10 Aug 2018 07:59:30 -0400
Eelco Chaudron <echaudro@redhat.com> wrote:
> + if (bs.bytes >= bs_hw.bytes && bs.packets >= bs_hw.packets) {
> + print_string(PRINT_FP, NULL, "%s", _SL_);
> + print_string(PRINT_FP, NULL, "%s", prefix);
> + print_lluint(PRINT_ANY, "sw_bytes",
> + "Sent software %llu bytes",
> + bs.bytes - bs_hw.bytes);
> + print_uint(PRINT_ANY, "sw_packets", " %u pkt",
> + bs.packets - bs_hw.packets);
> + }
> + }
> +
> + print_string(PRINT_FP, NULL, "%s", _SL_);
> + print_string(PRINT_FP, NULL, "%s", prefix);
> + print_lluint(PRINT_ANY, "hw_bytes", "Sent hardware %llu bytes",
> + bs_hw.bytes);
What does the output look like?
^ permalink raw reply
* Re: [PATCH v2 14/29] net: simplify eth_platform_get_mac_address()
From: Andy Shevchenko @ 2018-08-10 14:39 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180810080526.27207-15-brgl@bgdev.pl>
On Fri, Aug 10, 2018 at 11:05 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We don't need to use pci_device_to_OF_node() - we can retrieve
> dev->of_node directly even for pci devices.
>
> struct device_node *dp;
>
> - if (dev_is_pci(dev))
> - dp = pci_device_to_OF_node(to_pci_dev(dev));
> - else
> - dp = dev->of_node;
> -
> + dp = dev->of_node;
> addr = NULL;
> if (dp)
> addr = of_get_mac_address(dp);
Looking more at this I could even propose to change all above by
addr = device_get_mac_address(dev, mac_addr, ETH_ALEN);
Thoughts?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* KMSAN: uninit-value in ip_tunnel_xmit (2)
From: syzbot @ 2018-08-10 14:30 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 80ecacc456c1 kmsan: fix CONFIG_KMSAN=n build
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=163b7794400000
kernel config: https://syzkaller.appspot.com/x/.config?x=93d57043084eee38
dashboard link: https://syzkaller.appspot.com/bug?extid=4a2c52677a8a1aa283cb
compiler: clang version 7.0.0 (trunk 334104)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=17cec9dc400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145dcf0c400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4a2c52677a8a1aa283cb@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KMSAN: uninit-value in ip_tunnel_xmit+0x63a/0x3b10
net/ipv4/ip_tunnel.c:645
CPU: 1 PID: 4603 Comm: syz-executor712 Not tainted 4.18.0-rc4+ #27
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1e0 lib/dump_stack.c:113
kmsan_report+0x195/0x2c0 mm/kmsan/kmsan.c:982
__msan_warning+0x7d/0xe0 mm/kmsan/kmsan_instr.c:645
ip_tunnel_xmit+0x63a/0x3b10 net/ipv4/ip_tunnel.c:645
__gre_xmit net/ipv4/ip_gre.c:449 [inline]
ipgre_xmit+0xe16/0xef0 net/ipv4/ip_gre.c:701
__netdev_start_xmit include/linux/netdevice.h:4148 [inline]
netdev_start_xmit include/linux/netdevice.h:4157 [inline]
xmit_one net/core/dev.c:3034 [inline]
dev_hard_start_xmit+0x60f/0xcc0 net/core/dev.c:3050
__dev_queue_xmit+0x3060/0x3c70 net/core/dev.c:3569
dev_queue_xmit+0x4b/0x60 net/core/dev.c:3602
packet_snd net/packet/af_packet.c:2919 [inline]
packet_sendmsg+0x8469/0x9010 net/packet/af_packet.c:2944
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg net/socket.c:651 [inline]
___sys_sendmsg+0xed9/0x1350 net/socket.c:2125
__sys_sendmsg net/socket.c:2163 [inline]
__do_sys_sendmsg net/socket.c:2172 [inline]
__se_sys_sendmsg net/socket.c:2170 [inline]
__x64_sys_sendmsg+0x3b0/0x520 net/socket.c:2170
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x4412f9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffdc77f10d8 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004412f9
RDX: 0000000000000000 RSI: 0000000020000600 RDI: 0000000000000003
RBP: 00000000006cc018 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000020 R11: 0000000000000213 R12: 0000000000402260
R13: 00000000004022f0 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_internal_poison_shadow+0xc8/0x1d0 mm/kmsan/kmsan.c:181
kmsan_kmalloc+0xa1/0x120 mm/kmsan/kmsan_hooks.c:91
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:100
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2720 [inline]
__kmalloc_node_track_caller+0xb48/0x11d0 mm/slub.c:4353
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cb/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:988 [inline]
alloc_skb_with_frags+0x1e6/0xb80 net/core/skbuff.c:5271
sock_alloc_send_pskb+0xb59/0x11e0 net/core/sock.c:2095
packet_alloc_skb net/packet/af_packet.c:2776 [inline]
packet_snd net/packet/af_packet.c:2867 [inline]
packet_sendmsg+0x68cb/0x9010 net/packet/af_packet.c:2944
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg net/socket.c:651 [inline]
___sys_sendmsg+0xed9/0x1350 net/socket.c:2125
__sys_sendmsg net/socket.c:2163 [inline]
__do_sys_sendmsg net/socket.c:2172 [inline]
__se_sys_sendmsg net/socket.c:2170 [inline]
__x64_sys_sendmsg+0x3b0/0x520 net/socket.c:2170
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH v8 bpf-next 00/10] veth: Driver XDP
From: Daniel Borkmann @ 2018-08-10 14:24 UTC (permalink / raw)
To: Toshiaki Makita, Alexei Starovoitov
Cc: netdev, Jesper Dangaard Brouer, Jakub Kicinski, John Fastabend
In-Reply-To: <1533283098-2397-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
On 08/03/2018 09:58 AM, Toshiaki Makita wrote:
> This patch set introduces driver XDP for veth.
> Basically this is used in conjunction with redirect action of another XDP
> program.
>
> NIC -----------> veth===veth
> (XDP) (redirect) (XDP)
>
> In this case xdp_frame can be forwarded to the peer veth without
> modification, so we can expect far better performance than generic XDP.
>
>
> Envisioned use-cases
> --------------------
>
> * Container managed XDP program
> Container host redirects frames to containers by XDP redirect action, and
> privileged containers can deploy their own XDP programs.
>
> * XDP program cascading
> Two or more XDP programs can be called for each packet by redirecting
> xdp frames to veth.
>
> * Internal interface for an XDP bridge
> When using XDP redirection to create a virtual bridge, veth can be used
> to create an internal interface for the bridge.
>
>
> Implementation
> --------------
>
> This changeset is making use of NAPI to implement ndo_xdp_xmit and
> XDP_TX/REDIRECT. This is mainly because XDP heavily relies on NAPI
> context.
> - patch 1: Export a function needed for veth XDP.
> - patch 2-3: Basic implementation of veth XDP.
> - patch 4-6: Add ndo_xdp_xmit.
> - patch 7-9: Add XDP_TX and XDP_REDIRECT.
> - patch 10: Performance optimization for multi-queue env.
>
>
> Tests and performance numbers
> -----------------------------
>
> Tested with a simple XDP program which only redirects packets between
> NIC and veth. I used i40e 25G NIC (XXV710) for the physical NIC. The
> server has 20 of Xeon Silver 2.20 GHz cores.
>
> pktgen --(wire)--> XXV710 (i40e) <--(XDP redirect)--> veth===veth (XDP)
>
> The rightmost veth loads XDP progs and just does DROP or TX. The number
> of packets is measured in the XDP progs. The leftmost pktgen sends
> packets at 37.1 Mpps (almost 25G wire speed).
>
> veth XDP action Flows Mpps
> ================================
> DROP 1 10.6
> DROP 2 21.2
> DROP 100 36.0
> TX 1 5.0
> TX 2 10.0
> TX 100 31.0
>
> I also measured netperf TCP_STREAM but was not so great performance due
> to lack of tx/rx checksum offload and TSO, etc.
>
> netperf <--(wire)--> XXV710 (i40e) <--(XDP redirect)--> veth===veth (XDP PASS)
>
> Direction Flows Gbps
> ==============================
> external->veth 1 20.8
> external->veth 2 23.5
> external->veth 100 23.6
> veth->external 1 9.0
> veth->external 2 17.8
> veth->external 100 22.9
>
> Also tested doing ifup/down or load/unload a XDP program repeatedly
> during processing XDP packets in order to check if enabling/disabling
> NAPI is working as expected, and found no problems.
>
> v8:
> - Don't use xdp_frame pointer address to calculate skb->head, headroom,
> and xdp_buff.data_hard_start.
>
> v7:
> - Introduce xdp_scrub_frame() to clear kernel pointers in xdp_frame and
> use it instead of memset().
>
> v6:
> - Check skb->len only if reallocation is needed.
> - Add __GFP_NOWARN to alloc_page() since it can be triggered by external
> events.
> - Fix sparse warning around EXPORT_SYMBOL.
>
> v5:
> - Fix broken SOBs.
>
> v4:
> - Don't adjust MTU automatically.
> - Skip peer IFF_UP check on .ndo_xdp_xmit() because it is unnecessary.
> Add comments to explain that.
> - Use redirect_info instead of xdp_mem_info for storing no_direct flag
> to avoid per packet copy cost.
>
> v3:
> - Drop skb bulk xmit patch since it makes little performance
> difference. The hotspot in TCP skb xmit at this point is checksum
> computation in skb_segment and packet copy on XDP_REDIRECT due to
> cloned/nonlinear skb.
> - Fix race on closing device.
> - Add extack messages in ndo_bpf.
>
> v2:
> - Squash NAPI patch with "Add driver XDP" patch.
> - Remove conversion from xdp_frame to skb when NAPI is not enabled.
> - Introduce per-queue XDP ring (patch 8).
> - Introduce bulk skb xmit when XDP is enabled on the peer (patch 9).
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> Toshiaki Makita (10):
> net: Export skb_headers_offset_update
> veth: Add driver XDP
> veth: Avoid drops by oversized packets when XDP is enabled
> xdp: Helper function to clear kernel pointers in xdp_frame
> veth: Handle xdp_frames in xdp napi ring
> veth: Add ndo_xdp_xmit
> bpf: Make redirect_info accessible from modules
> xdp: Helpers for disabling napi_direct of xdp_return_frame
> veth: Add XDP TX and REDIRECT
> veth: Support per queue XDP ring
>
> drivers/net/veth.c | 750 ++++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/filter.h | 35 +++
> include/linux/skbuff.h | 1 +
> include/net/xdp.h | 7 +
> net/core/filter.c | 29 +-
> net/core/skbuff.c | 3 +-
> net/core/xdp.c | 6 +-
> 7 files changed, 801 insertions(+), 30 deletions(-)
>
Applied to bpf-next, thanks Toshiaki!
^ permalink raw reply
* Re: [bpf-next V2 PATCH 0/2] Implement sample code for XDP cpumap IP-pair load-balancing
From: Daniel Borkmann @ 2018-08-10 14:10 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev
Cc: victor, eric, Daniel Borkmann, Alexei Starovoitov, jhsiao
In-Reply-To: <153390254528.10825.9125109091513926669.stgit@firesoul>
On 08/10/2018 02:02 PM, Jesper Dangaard Brouer wrote:
> Background: cpumap moves the SKB allocation out of the driver code,
> and instead allocate it on the remote CPU, and invokes the regular
> kernel network stack with the newly allocated SKB.
>
> The idea behind the XDP CPU redirect feature, is to use XDP as a
> load-balancer step in-front of regular kernel network stack. But the
> current sample code does not provide a good example of this. Part of
> the reason is that, I have implemented this as part of Suricata XDP
> load-balancer.
>
> Given this is the most frequent feature request I get. This patchset
> implement the same XDP load-balancing as Suricata does, which is a
> symmetric hash based on the IP-pairs + L4-protocol.
>
> The expected setup for the use-case is to reduce the number of NIC RX
> queues via ethtool (as XDP can handle more per core), and via
> smp_affinity assign these RX queues to a set of CPUs, which will be
> handling RX packets. The CPUs that runs the regular network stack is
> supplied to the sample xdp_redirect_cpu tool by specifying
> the --cpu option multiple times on the cmdline.
>
> I do note that cpumap SKB creation is not feature complete yet, and
> more work is coming. E.g. given GRO is not implemented yet, do expect
> TCP workloads to be slower. My measurements do indicate UDP workloads
> are faster.
Applied to bpf-next, thanks Jesper!
^ 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