* [PATCH v2 net] inet: frags: better deal with smp races
From: Eric Dumazet @ 2018-11-09 1:34 UTC (permalink / raw)
To: David S . Miller
Cc: netdev, Eric Dumazet, Eric Dumazet, 배석진
Multiple cpus might attempt to insert a new fragment in rhashtable,
if for example RPS is buggy, as reported by 배석진 in
https://patchwork.ozlabs.org/patch/994601/
We use rhashtable_lookup_get_insert_key() instead of
rhashtable_insert_fast() to let cpus losing the race
free their own inet_frag_queue and use the one that
was inserted by another cpu.
Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: 배석진 <soukjin.bae@samsung.com>
---
net/ipv4/inet_fragment.c | 29 +++++++++++++++--------------
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index bcb11f3a27c0c34115af05034a5a20f57842eb0a..760a9e52e02b91b36af323c92f7027e150858f88 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -178,21 +178,22 @@ static struct inet_frag_queue *inet_frag_alloc(struct netns_frags *nf,
}
static struct inet_frag_queue *inet_frag_create(struct netns_frags *nf,
- void *arg)
+ void *arg,
+ struct inet_frag_queue **prev)
{
struct inet_frags *f = nf->f;
struct inet_frag_queue *q;
- int err;
q = inet_frag_alloc(nf, f, arg);
- if (!q)
+ if (!q) {
+ *prev = ERR_PTR(-ENOMEM);
return NULL;
-
+ }
mod_timer(&q->timer, jiffies + nf->timeout);
- err = rhashtable_insert_fast(&nf->rhashtable, &q->node,
- f->rhash_params);
- if (err < 0) {
+ *prev = rhashtable_lookup_get_insert_key(&nf->rhashtable, &q->key,
+ &q->node, f->rhash_params);
+ if (*prev) {
q->flags |= INET_FRAG_COMPLETE;
inet_frag_kill(q);
inet_frag_destroy(q);
@@ -204,22 +205,22 @@ static struct inet_frag_queue *inet_frag_create(struct netns_frags *nf,
/* TODO : call from rcu_read_lock() and no longer use refcount_inc_not_zero() */
struct inet_frag_queue *inet_frag_find(struct netns_frags *nf, void *key)
{
- struct inet_frag_queue *fq;
+ struct inet_frag_queue *fq = NULL, *prev;
if (!nf->high_thresh || frag_mem_limit(nf) > nf->high_thresh)
return NULL;
rcu_read_lock();
- fq = rhashtable_lookup(&nf->rhashtable, key, nf->f->rhash_params);
- if (fq) {
+ prev = rhashtable_lookup(&nf->rhashtable, key, nf->f->rhash_params);
+ if (!prev)
+ fq = inet_frag_create(nf, key, &prev);
+ if (prev && !IS_ERR(prev)) {
+ fq = prev;
if (!refcount_inc_not_zero(&fq->refcnt))
fq = NULL;
- rcu_read_unlock();
- return fq;
}
rcu_read_unlock();
-
- return inet_frag_create(nf, key);
+ return fq;
}
EXPORT_SYMBOL(inet_frag_find);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* Re: [PATCH] [stable, netdev 4.4+] lan78xx: make sure RX_ADDRL & RX_ADDRH regs are always up to date
From: Paolo Pisati @ 2018-11-09 11:31 UTC (permalink / raw)
To: Sasha Levin
Cc: Paolo Pisati, Woojung Huh, Microchip Linux Driver Support, netdev,
stable, linux-usb, linux-kernel
In-Reply-To: <20181108154904.GD8097@sasha-vm>
On Thu, Nov 08, 2018 at 10:49:04AM -0500, Sasha Levin wrote:
>
> Can you confirm it actually works on 4.4?
Yes, built and tested on 4.4.y:
Tested-by: Paolo Pisati <p.pisati@gmail.com>
--
bye,
p.
^ permalink raw reply
* Re: (2) (2) (2) (2) [Kernel][NET] Bug report on packet defragmenting
From: Eric Dumazet @ 2018-11-09 1:58 UTC (permalink / raw)
To: soukjin.bae, Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <1181390155.1787604.1541724136242.JavaMail.jboss@ep1ml102>
On 11/08/2018 04:42 PM, 배석진 wrote:
>> Thanks for testing.
>>
>> This is not a pristine net-next tree, this dump seems unrelated to the patch ?
>
>
> yes, looks like that.
> but only when using your patch, panic came. even right after packet recieving..
> without that, there's no problem except defrag issue. it's odd.. :p
> I couldn't more debugging since have other problems.
You might need to backport some fixes (check all changes to lib/rhashtable.c )
^ permalink raw reply
* RE:(2) (2) (2) (2) (2) [Kernel][NET] Bug report on packet defragmenting
From: 배석진 @ 2018-11-09 2:24 UTC (permalink / raw)
To: Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <716b4f59-eac1-ba74-c39e-b9918b25b073@gmail.com>
>On 11/08/2018 04:42 PM, 배석진 wrote:
>> Thanks for testing.
>>>
>>> This is not a pristine net-next tree, this dump seems unrelated to the patch ?
>>
>>
>> yes, looks like that.
>> but only when using your patch, panic came. even right after packet recieving..
>> without that, there's no problem except defrag issue. it's odd.. :p
>> I couldn't more debugging since have other problems.
>
>
> You might need to backport some fixes (check all changes to lib/rhashtable.c )
I try to backport the updates to my space.
but.. there are too many related files about lib/rhashtable.c ..
I give up ;(
thank you for your help!
^ permalink raw reply
* Re: net: ipv4: tcp_westwood
From: Suraj Singh @ 2018-11-09 12:18 UTC (permalink / raw)
To: davem; +Cc: kuznet, yoshfuji, netdev, linux-kernel, suraj1998, LinoSanfilippo
In-Reply-To: <1541670377-17483-1-git-send-email-suraj1998@gmail.com>
Hi Lino,
Thank you for clarifying the doubts I had and for the suggestion on where to
start contributing. Previously, and in this patch I hadn't configured mutt
and was manually using git send-mail to respond to each thread using the
corresponding mail-id. That's why I wasn't sure why even in this patch,
"staging: " had appeared even after editing the commit message. Now that I've
got the email client setup, I'll fix that "staging: " issue and send a [v3]
patch.
^ permalink raw reply
* Re: [PATCH v2 net] inet: frags: better deal with smp races
From: David Miller @ 2018-11-09 2:41 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, soukjin.bae
In-Reply-To: <20181109013427.218098-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 8 Nov 2018 17:34:27 -0800
> Multiple cpus might attempt to insert a new fragment in rhashtable,
> if for example RPS is buggy, as reported by 배석진 in
> https://patchwork.ozlabs.org/patch/994601/
>
> We use rhashtable_lookup_get_insert_key() instead of
> rhashtable_insert_fast() to let cpus losing the race
> free their own inet_frag_queue and use the one that
> was inserted by another cpu.
>
> Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: 배석진 <soukjin.bae@samsung.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH net-next] tcp_bbr: update comments to reflect pacing_margin_percent
From: Neal Cardwell @ 2018-11-09 2:54 UTC (permalink / raw)
To: David Miller
Cc: netdev, Neal Cardwell, Yuchung Cheng, Soheil Hassas Yeganeh,
Eric Dumazet
Recently, in commit ab408b6dc744 ("tcp: switch tcp and sch_fq to new
earliest departure time model"), the TCP BBR code switched to a new
approach of using an explicit bbr_pacing_margin_percent for shaving a
pacing rate "haircut", rather than the previous implict
approach. Update an old comment to reflect the new approach.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp_bbr.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/tcp_bbr.c b/net/ipv4/tcp_bbr.c
index 9277abdd822a0..0f497fc49c3fe 100644
--- a/net/ipv4/tcp_bbr.c
+++ b/net/ipv4/tcp_bbr.c
@@ -128,7 +128,12 @@ static const u32 bbr_probe_rtt_mode_ms = 200;
/* Skip TSO below the following bandwidth (bits/sec): */
static const int bbr_min_tso_rate = 1200000;
-/* Pace at ~1% below estimated bw, on average, to reduce queue at bottleneck. */
+/* Pace at ~1% below estimated bw, on average, to reduce queue at bottleneck.
+ * In order to help drive the network toward lower queues and low latency while
+ * maintaining high utilization, the average pacing rate aims to be slightly
+ * lower than the estimated bandwidth. This is an important aspect of the
+ * design.
+ */
static const int bbr_pacing_margin_percent = 1;
/* We use a high_gain value of 2/ln(2) because it's the smallest pacing gain
@@ -247,13 +252,7 @@ static void bbr_init_pacing_rate_from_rtt(struct sock *sk)
sk->sk_pacing_rate = bbr_bw_to_pacing_rate(sk, bw, bbr_high_gain);
}
-/* Pace using current bw estimate and a gain factor. In order to help drive the
- * network toward lower queues while maintaining high utilization and low
- * latency, the average pacing rate aims to be slightly (~1%) lower than the
- * estimated bandwidth. This is an important aspect of the design. In this
- * implementation this slightly lower pacing rate is achieved implicitly by not
- * including link-layer headers in the packet size used for the pacing rate.
- */
+/* Pace using current bw estimate and a gain factor. */
static void bbr_set_pacing_rate(struct sock *sk, u32 bw, int gain)
{
struct tcp_sock *tp = tcp_sk(sk);
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* Re: net: ipv4: tcp_vegas
From: Suraj Singh @ 2018-11-09 12:37 UTC (permalink / raw)
To: davem; +Cc: kuznet, yoshfuji, netdev, linux-kernel, suraj1998
In-Reply-To: <1541665792-5888-1-git-send-email-suraj1998@gmail.com>
Hi,
I'm extremely sorry if I have seemed unresponsive to you but it took me a
while to figure out how to respond to threads using the corresponding mail
-id. I think the first two comments that you wrote on my initial patch with
message-id: 1541425985-31869-1-git-send-email-suraj1998@gmail.com were being
redirected to my spam folder and since I didn't have mutt configured
then, I didn't see them,
The reason I've been prefixing all the subject of my mails with "staging: "
is because I was following Greg Kroah-Hartman's YouTube video on how to
submit your first kernel patch. I didn't realise the significance of using
it and didn't take the time out to understand what it really meant and that
is my bad. I've got clarifications for the same in comments to the patch with
message-id: 1541670377-17483-1-git-send-email-suraj1998@gmail.com
I think what I will do is first figure out how to use mutt effectively before
sending subsequent patches and emails because all the emails that I have sent
(including this one), I've done so by manually writing git send-mail commands
in response to the corresponding message-id.
Other than unwarranted "staging: " in the subject, are there any other changes
that need to be made before I submit [v3] of the second tcp_westwood patch
(1541670377-17483-1-git-send-email-suraj1998@gmail.com)?
Regards,
Suraj
^ permalink raw reply
* Re: [PATCH ipsec-next 00/11] xfrm: policy: add inexact policy search tree
From: David Miller @ 2018-11-09 3:00 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20181107220041.26205-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 7 Nov 2018 23:00:30 +0100
> This series attempts to improve xfrm policy lookup performance when
> a lot of (several hundred or even thousands) inexact policies exist
> on a system.
>
> On insert, a policy is either placed in hash table (all direct (/32 for
> ipv4, /128 policies, or all policies matching a user-configured threshold).
> All other policies get inserted into inexact list as per priority.
>
> Lookup then scans inexact list for first matching entry.
>
> This series instead makes it so that inexact policy is added to exactly
> one of four different search list classes.
>
> 1. "Any:Any" list, containing policies where both saddr and daddr are
> wildcards or have very coarse prefixes, e.g. 10.0.0.0/8 and the like.
> 2. "saddr:any" list, containing policies with a fixed saddr/prefixlen,
> but without destination restrictions.
> These lists are stored in rbtree nodes; each node contains those
> policies matching saddr/prefixlen.
> 3. "Any:daddr" list. Similar to 2), except for policies where only the
> destinations are specified.
> 4. "saddr:daddr" lists, containing policies that match the given
> source/destination network.
>
> The root of the saddr/daddr tree is stored in the nodes of the
> 'daddr' tree.
...
> Comments or questions welcome.
Acked-by: David S. Miller <davem@davemloft.net>
This looks really great. Nice work Florian.
^ permalink raw reply
* Re: [PATCH] net: Add trace events for all receive exit points
From: Genevieve Bastien @ 2018-11-09 2:56 UTC (permalink / raw)
To: Mathieu Desnoyers; +Cc: David S. Miller, netdev, rostedt, Ingo Molnar
In-Reply-To: <1057796879.2336.1541708744442.JavaMail.zimbra@efficios.com>
On 2018-11-08 03:25 PM, Mathieu Desnoyers wrote:
> ----- On Nov 8, 2018, at 2:56 PM, Geneviève Bastien gbastien@versatic.net wrote:
>
>> Trace events are already present for the receive entry points, to indicate
>> how the reception entered the stack.
>>
>> This patch adds the corresponding exit trace events that will bound the
>> reception such that all events occurring between the entry and the exit
>> can be considered as part of the reception context. This greatly helps
>> for dependency and root cause analyses.
>>
>> Without this, it is impossible to determine whether a sched_wakeup
>> event following a netif_receive_skb event is the result of the packet
>> reception or a simple coincidence after further processing by the
>> thread.
> As a clarification: it is indeed not possible with tracepoint instrumentation,
> which I think is your point here. It might be possible to do so by using other
> mechanisms like kretprobes, but considering that the "entry" point was deemed
> important enough to have a tracepoint, it would be good to add the matching exit
> events.
>
> Being able to link the packet reception entry/exit with wakeups is key to
> allow tools to perform automated network stack latency analysis, so I think
> the use case justifies adding the missing "exit" events.
Thanks for the precision. Indeed so far, kretprobes have been used as a
workaround, but it is harder to setup and has quite more overhead. After
seeing those "entry" points, I thought corresponding "exits" would be
the best candidate to encapsulate the "network reception" context.
For an example of dependency and critical path analysis of 'wget', see
this screenshot here, arranged from Trace Compass:
https://framapic.org/DgSdNwiuymib/PDPdHJBGCJGR.png
The top view shows the dependency analysis without the "exit" events:
the wakeup is not associated with the packet reception, so the source is
considered to be the process that was running at that time, an IRQ
thread. So wget was blocked by the iwlwifi IRQ thread, who was himself
simply woken up by an hardware interrupt, while in fact, wget was
waiting for the network.
The bottom view shows the dependency analysis with the "exit" events:
because the wakeup happens between the "entry" and "exit", we know the
packet reception is the source of the wakeup and if we happen to know
where that packet came from, we can follow the dependency to the packet
source. So wget was blocked waiting for a network request to another
machine which sent back the reply and we clearly see the time spent on
the other machine and the network latency during this blockage.
I hope this kind of possibilities for analyses justify adding those
tracepoints.
Thanks,
Geneviève
>
> It might be great if you can provide a glimpse of the wakeup dependency chain
> analysis prototypes you have created, which rely on this new event, in order
> to justify adding it.
>
> Thanks,
>
> Mathieu
>
>> Signed-off-by: Geneviève Bastien <gbastien@versatic.net>
>> CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> CC: Steven Rostedt <rostedt@goodmis.org>
>> CC: Ingo Molnar <mingo@redhat.com>
>> CC: David S. Miller <davem@davemloft.net>
>> ---
>> include/trace/events/net.h | 59 ++++++++++++++++++++++++++++++++++++++
>> net/core/dev.c | 30 ++++++++++++++++---
>> 2 files changed, 85 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/trace/events/net.h b/include/trace/events/net.h
>> index 00aa72ce0e7c..318307511018 100644
>> --- a/include/trace/events/net.h
>> +++ b/include/trace/events/net.h
>> @@ -117,6 +117,23 @@ DECLARE_EVENT_CLASS(net_dev_template,
>> __get_str(name), __entry->skbaddr, __entry->len)
>> )
>>
>> +DECLARE_EVENT_CLASS(net_dev_template_simple,
>> +
>> + TP_PROTO(struct sk_buff *skb),
>> +
>> + TP_ARGS(skb),
>> +
>> + TP_STRUCT__entry(
>> + __field(void *, skbaddr)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->skbaddr = skb;
>> + ),
>> +
>> + TP_printk("skbaddr=%p", __entry->skbaddr)
>> +)
>> +
>> DEFINE_EVENT(net_dev_template, net_dev_queue,
>>
>> TP_PROTO(struct sk_buff *skb),
>> @@ -244,6 +261,48 @@ DEFINE_EVENT(net_dev_rx_verbose_template,
>> netif_rx_ni_entry,
>> TP_ARGS(skb)
>> );
>>
>> +DEFINE_EVENT(net_dev_template_simple, napi_gro_frags_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb),
>> +
>> + TP_ARGS(skb)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_simple, napi_gro_receive_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb),
>> +
>> + TP_ARGS(skb)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_simple, netif_receive_skb_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb),
>> +
>> + TP_ARGS(skb)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_simple, netif_receive_skb_list_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb),
>> +
>> + TP_ARGS(skb)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_simple, netif_rx_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb),
>> +
>> + TP_ARGS(skb)
>> +);
>> +
>> +DEFINE_EVENT(net_dev_template_simple, netif_rx_ni_exit,
>> +
>> + TP_PROTO(struct sk_buff *skb),
>> +
>> + TP_ARGS(skb)
>> +);
>> +
>> #endif /* _TRACE_NET_H */
>>
>> /* This part must be outside protection */
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 0ffcbdd55fa9..e670ca27e829 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4520,9 +4520,14 @@ static int netif_rx_internal(struct sk_buff *skb)
>>
>> int netif_rx(struct sk_buff *skb)
>> {
>> + int ret;
>> +
>> trace_netif_rx_entry(skb);
>>
>> - return netif_rx_internal(skb);
>> + ret = netif_rx_internal(skb);
>> + trace_netif_rx_exit(skb);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(netif_rx);
>>
>> @@ -4537,6 +4542,7 @@ int netif_rx_ni(struct sk_buff *skb)
>> if (local_softirq_pending())
>> do_softirq();
>> preempt_enable();
>> + trace_netif_rx_ni_exit(skb);
>>
>> return err;
>> }
>> @@ -5222,9 +5228,14 @@ static void netif_receive_skb_list_internal(struct
>> list_head *head)
>> */
>> int netif_receive_skb(struct sk_buff *skb)
>> {
>> + int ret;
>> +
>> trace_netif_receive_skb_entry(skb);
>>
>> - return netif_receive_skb_internal(skb);
>> + ret = netif_receive_skb_internal(skb);
>> + trace_netif_receive_skb_exit(skb);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(netif_receive_skb);
>>
>> @@ -5247,6 +5258,8 @@ void netif_receive_skb_list(struct list_head *head)
>> list_for_each_entry(skb, head, list)
>> trace_netif_receive_skb_list_entry(skb);
>> netif_receive_skb_list_internal(head);
>> + list_for_each_entry(skb, head, list)
>> + trace_netif_receive_skb_list_exit(skb);
>> }
>> EXPORT_SYMBOL(netif_receive_skb_list);
>>
>> @@ -5634,12 +5647,17 @@ static gro_result_t napi_skb_finish(gro_result_t ret,
>> struct sk_buff *skb)
>>
>> gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
>> {
>> + gro_result_t ret;
>> +
>> skb_mark_napi_id(skb, napi);
>> trace_napi_gro_receive_entry(skb);
>>
>> skb_gro_reset_offset(skb);
>>
>> - return napi_skb_finish(dev_gro_receive(napi, skb), skb);
>> + ret = napi_skb_finish(dev_gro_receive(napi, skb), skb);
>> + trace_napi_gro_receive_exit(skb);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(napi_gro_receive);
>>
>> @@ -5753,6 +5771,7 @@ static struct sk_buff *napi_frags_skb(struct napi_struct
>> *napi)
>>
>> gro_result_t napi_gro_frags(struct napi_struct *napi)
>> {
>> + gro_result_t ret;
>> struct sk_buff *skb = napi_frags_skb(napi);
>>
>> if (!skb)
>> @@ -5760,7 +5779,10 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
>>
>> trace_napi_gro_frags_entry(skb);
>>
>> - return napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
>> + ret = napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
>> + trace_napi_gro_frags_exit(skb);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(napi_gro_frags);
>>
>> --
>> 2.19.1
^ permalink raw reply
* Should the bridge learn from frames with link local destination MAC address?
From: Andrew Lunn @ 2018-11-09 3:24 UTC (permalink / raw)
To: Roopa Prabhu, Nikolay Aleksandrov; +Cc: netdev, Florian Fainelli
Hi Roopa, Nikolay
br_handle_frame() looks out for frames with a destination MAC
addresses with is Ethernet link local, those which fit
01-80-C2-00-00-XX. It does not normally forward these, but it will
deliver them locally.
Should the bridge perform learning on such frames?
I've got a setup with two bridges connected together with multiple
links between them. STP has done its thing, and blocked one of the
ports to solve the loop.
host0 host1
+-----------------+ +-----------------+
| lan0 forwarding |-----| lan0 forwarding |
| | | |
| lan1 forwarding |-----| lan1 blocked |
+-----------------+ +-----------------+
I have LLDP running on both system, and they are sending out periodic
frames on each port.
Now, lan0 and lan1 on host1 use the same MAC address. So i see the
MAC address bouncing between ports because of the LLDP packets.
# bridge monitor
00:26:55:d2:27:a8 dev lan1 master br0
00:26:55:d2:27:a8 dev lan0 master br0
00:26:55:d2:27:a8 dev lan1 master br0
00:26:55:d2:27:a8 dev lan0 master br0
00:26:55:d2:27:a8 dev lan1 master br0
This then results in normal traffic from host0 to host1 being sent to
the blocked port for some of the time.
LLDP is using 01-80-C2-00-00-0E, a link local MAC address. If the
bridge did not learn on such frames, i think this setup would
work. The bridge would learn from ARP, IP etc, coming from the
forwarding port of host1, and the blocked port would be ignored.
I've tried a similar setup with a hardware switch, Marvell 6352. It
never seems to learn from such frames.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next] dpaa2-eth: Introduce TX congestion management
From: David Miller @ 2018-11-09 3:26 UTC (permalink / raw)
To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei
In-Reply-To: <AM0PR04MB4994571246CB1708B79A986594C50@AM0PR04MB4994.eurprd04.prod.outlook.com>
From: Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>
Date: Thu, 8 Nov 2018 20:21:15 +0000
> Today I tried to further coalesce the confirmation frames such that I call
> netdev_tx_completed_queue() only at the end of the NAPI poll, once for each
> confirmation queue that was serviced during that NAPI.
That sounds like exactly what you should do given your design description.
> I need to do more testing, but so far it performs *almost* on par
> with the non-BQL driver version. But it does complicate the fastpath
> code and feels somewhat unnatural.
Well, this is exactly what should happen with BQL and as a result you will
get much better TCP queue utilization and avoidance of bufferbloat.
^ permalink raw reply
* Re: [PATCH net-next 0/2] dpaa2-eth: defer probe on object allocate
From: David Miller @ 2018-11-09 3:28 UTC (permalink / raw)
To: ioana.ciornei; +Cc: netdev, ruxandra.radulescu
In-Reply-To: <1541683054-22273-1-git-send-email-ioana.ciornei@nxp.com>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
Date: Thu, 8 Nov 2018 13:17:46 +0000
> Allocatable objects on the fsl-mc bus may be probed by the fsl_mc_allocator
> after the first attempts of other drivers to use them. Defer the probe when
> this situation happens.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] dpaa2-eth: defer probe on object allocate
From: David Miller @ 2018-11-09 3:29 UTC (permalink / raw)
To: ioana.ciornei; +Cc: netdev, ruxandra.radulescu
In-Reply-To: <20181108.192857.2194316658343454675.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 08 Nov 2018 19:28:57 -0800 (PST)
> From: Ioana Ciornei <ioana.ciornei@nxp.com>
> Date: Thu, 8 Nov 2018 13:17:46 +0000
>
>> Allocatable objects on the fsl-mc bus may be probed by the fsl_mc_allocator
>> after the first attempts of other drivers to use them. Defer the probe when
>> this situation happens.
>
> Series applied, thanks.
Whoops, I just saw Andrew Lunn's feedback.
I reverted your changes, please address his concerns and resubmit.
Thank you.
^ permalink raw reply
* Re: [PATCH v3 net-next] sock: Reset dst when changing sk_mark via setsockopt
From: David Miller @ 2018-11-09 3:36 UTC (permalink / raw)
To: david.barmann; +Cc: netdev
In-Reply-To: <20181108141335.GA29455@konacove.com>
From: David Barmann <david.barmann@stackpath.com>
Date: Thu, 8 Nov 2018 08:13:35 -0600
> When setting the SO_MARK socket option, if the mark changes, the dst
> needs to be reset so that a new route lookup is performed.
>
> This fixes the case where an application wants to change routing by
> setting a new sk_mark. If this is done after some packets have already
> been sent, the dst is cached and has no effect.
>
> Signed-off-by: David Barmann <david.barmann@stackpath.com>
Applied.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 2/7] libbpf: cleanup after partial failure in bpf_object__pin
From: Jakub Kicinski @ 2018-11-09 3:37 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, linux-kselftest, ast, daniel, shuah, quentin.monnet, guro,
jiong.wang, sdf, bhole_prashant_q7, john.fastabend, jbenc,
treeze.taeung, yhs, osk, sandipan
In-Reply-To: <20181109002213.5914-3-s@fomichev.me>
On Thu, 8 Nov 2018 16:22:08 -0800, Stanislav Fomichev wrote:
> + for (map = bpf_map__prev(map, obj);
> + map != NULL;
> + map = bpf_map__prev(map, obj)) {
nit pick: if you need to respin all these for loops on error paths could
have been more concise while loops
^ permalink raw reply
* Re: [PATCH net 0/4] Slowpath Queue bug fixes
From: David Miller @ 2018-11-09 3:38 UTC (permalink / raw)
To: denis.bolotin; +Cc: netdev, ariel.elior, michal.kalderon
In-Reply-To: <20181108144611.28598-1-denis.bolotin@cavium.com>
From: Denis Bolotin <denis.bolotin@cavium.com>
Date: Thu, 8 Nov 2018 16:46:07 +0200
> This patch series fixes several bugs in the SPQ mechanism.
> It deals with SPQ entries management, preventing resource leaks, memory
> corruptions and handles error cases throughout the driver.
> Please consider applying to net.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 4/7] libbpf: add internal pin_name
From: Jakub Kicinski @ 2018-11-09 3:38 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, linux-kselftest, ast, daniel, shuah, quentin.monnet, guro,
jiong.wang, sdf, bhole_prashant_q7, john.fastabend, jbenc,
treeze.taeung, yhs, osk, sandipan
In-Reply-To: <20181109002213.5914-5-s@fomichev.me>
On Thu, 8 Nov 2018 16:22:10 -0800, Stanislav Fomichev wrote:
> @@ -261,6 +266,18 @@ static void bpf_program__exit(struct bpf_program *prog)
> prog->idx = -1;
> }
>
> +static char *__bpf_program__pin_name(struct bpf_program *prog)
> +{
> + char *name;
> +
> + name = strdup(prog->section_name);
> + for (char *p = name; p && *p; p++)
Useful patch! I'm not sure about libbpf but in the kernel we don't do
C99 variable declarations inside for loop init. Perhaps better to stick
to kernel rules than invent our own.
Also, I'm tempted to say:
char *name, *p;
name = p = strdup(prog->section_name);
while ((p = strchr(p, '/')))
*p = '_';
;)
> + if (*p == '/')
> + *p = '_';
> +
> + return name;
> +}
^ permalink raw reply
* Re: [PATCH v4 bpf-next 5/7] bpftool: add loadall command
From: Jakub Kicinski @ 2018-11-09 3:41 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, linux-kselftest, ast, daniel, shuah, quentin.monnet, guro,
jiong.wang, sdf, bhole_prashant_q7, john.fastabend, jbenc,
treeze.taeung, yhs, osk, sandipan
In-Reply-To: <20181109002213.5914-6-s@fomichev.me>
On Thu, 8 Nov 2018 16:22:11 -0800, Stanislav Fomichev wrote:
> @@ -79,8 +80,13 @@ DESCRIPTION
> contain a dot character ('.'), which is reserved for future
> extensions of *bpffs*.
>
> - **bpftool prog load** *OBJ* *FILE* [**type** *TYPE*] [**map** {**idx** *IDX* | **name** *NAME*} *MAP*] [**dev** *NAME*]
> - Load bpf program from binary *OBJ* and pin as *FILE*.
> + **bpftool prog { load | loadall }** *OBJ* *FILE* [**type** *TYPE*] [**map** {**idx** *IDX* | **name** *NAME*} *MAP*] [**dev** *NAME*]
> + Load bpf program(s) from binary *OBJ* and pin as *FILE*.
> + Both **bpftool prog load** and **bpftool prog loadall** load
> + all maps and programs from the *OBJ* and differ only in
> + pinning. **load** pins only the first program from the *OBJ*
> + as *FILE*. **loadall** pins all programs from the *OBJ*
> + under *FILE* directory.
> **type** is optional, if not specified program type will be
> inferred from section names.
> By default bpftool will create new maps as declared in the ELF
As I said the fact that we load all always is a libbpf limitation,
I wouldn't put it in documentation as it may change.
With that removed looks good to me:
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: [net-next, PATCH 1/2] net: socionext: different approach on DMA
From: David Miller @ 2018-11-09 3:42 UTC (permalink / raw)
To: ilias.apalodimas
Cc: netdev, jaswinder.singh, ard.biesheuvel, masami.hiramatsu,
masahisa.kojima, brouer, arnd
In-Reply-To: <1541690395-8337-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 8 Nov 2018 17:19:54 +0200
> Current driver dynamically allocates an skb and maps it as DMA Rx
> buffer. In order to prepare for upcoming XDP changes, let's introduce a
> different allocation scheme.
> Buffers are allocated dynamically and mapped into hardware.
> During the Rx operation the driver uses build_skb() to produce the
> necessary buffers for the network stack.
> This change increases performance ~15% on 64b packets with smmu disabled
> and ~5% with smmu enabled
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied.
^ permalink raw reply
* Re: [net-next, PATCH 2/2] net: socionext: refactor netsec_alloc_dring()
From: David Miller @ 2018-11-09 3:43 UTC (permalink / raw)
To: ilias.apalodimas
Cc: netdev, jaswinder.singh, ard.biesheuvel, masami.hiramatsu,
masahisa.kojima, brouer, arnd
In-Reply-To: <1541690395-8337-2-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 8 Nov 2018 17:19:55 +0200
> return -ENOMEM directly instead of assigning it in a variable
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 6/7] bpftool: add pinmaps argument to the load/loadall
From: Jakub Kicinski @ 2018-11-09 3:43 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, linux-kselftest, ast, daniel, shuah, quentin.monnet, guro,
jiong.wang, sdf, bhole_prashant_q7, john.fastabend, jbenc,
treeze.taeung, yhs, osk, sandipan
In-Reply-To: <20181109002213.5914-7-s@fomichev.me>
On Thu, 8 Nov 2018 16:22:12 -0800, Stanislav Fomichev wrote:
> From: Stanislav Fomichev <sdf@google.com>
>
> This new additional argument lets users pin all maps from the object at
> specified path.
>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* [PATCH] Bluetooth: clean an indentation issue, remove extraneous space
From: Colin King @ 2018-11-09 13:27 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, linux-bluetooth,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to clean up an indentation issue
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/bluetooth/hci_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index e8c9ef1e1922..ca73d36cc149 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -1556,7 +1556,7 @@ int __hci_req_setup_ext_adv_instance(struct hci_request *req, u8 instance)
connectable = (flags & MGMT_ADV_FLAG_CONNECTABLE) ||
mgmt_get_connectable(hdev);
- if (!is_advertising_allowed(hdev, connectable))
+ if (!is_advertising_allowed(hdev, connectable))
return -EPERM;
/* Set require_privacy to true only when non-connectable
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net-next 0/4] Remove VLAN_TAG_PRESENT from drivers
From: David Miller @ 2018-11-09 3:49 UTC (permalink / raw)
To: mirq-linux
Cc: netdev, claudiu.manoil, faisal.latif, pshelar, shiraz.saleem, dev,
linux-rdma
In-Reply-To: <cover.1541698641.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Thu, 08 Nov 2018 18:44:46 +0100
> This series removes VLAN_TAG_PRESENT use from network drivers in
> preparation to removing its special meaning.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 7/7] bpftool: support loading flow dissector
From: Jakub Kicinski @ 2018-11-09 3:50 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: netdev, linux-kselftest, ast, daniel, shuah, quentin.monnet, guro,
jiong.wang, sdf, bhole_prashant_q7, john.fastabend, jbenc,
treeze.taeung, yhs, osk, sandipan
In-Reply-To: <20181109002213.5914-8-s@fomichev.me>
On Thu, 8 Nov 2018 16:22:13 -0800, Stanislav Fomichev wrote:
> From: Stanislav Fomichev <sdf@google.com>
>
> This commit adds support for loading/attaching/detaching flow
> dissector program. The structure of the flow dissector program is
> assumed to be the same as in the selftests:
nit: I don't think we make any assumptions any more? Since the
sub-programs are added to the map explicitly by the user?
> * flow_dissector section with the main entry point
> * a bunch of tail call progs
> * a jmp_table map that is populated with the tail call progs
>
[...]
> @@ -338,7 +339,16 @@ _bpftool()
>
> case $prev in
> type)
> - COMPREPLY=( $( compgen -W "socket kprobe kretprobe classifier action tracepoint raw_tracepoint xdp perf_event cgroup/skb cgroup/sock cgroup/dev lwt_in lwt_out lwt_xmit lwt_seg6local sockops sk_skb sk_msg lirc_mode2 cgroup/bind4 cgroup/bind6 cgroup/connect4 cgroup/connect6 cgroup/sendmsg4 cgroup/sendmsg6 cgroup/post_bind4 cgroup/post_bind6" -- \
> + COMPREPLY=( $( compgen -W "socket kprobe \
> + kretprobe classifier flow_dissector \
> + action tracepoint raw_tracepoint \
> + xdp perf_event cgroup/skb cgroup/sock \
> + cgroup/dev lwt_in lwt_out lwt_xmit \
> + lwt_seg6local sockops sk_skb sk_msg \
> + lirc_mode2 cgroup/bind4 cgroup/bind6 \
> + cgroup/connect4 cgroup/connect6 \
> + cgroup/sendmsg4 cgroup/sendmsg6 \
> + cgroup/post_bind4 cgroup/post_bind6" -- \
> "$cur" ) )
Thanks! :)
> return 0
> ;;
> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
> index 4654d9450cd9..b808a67d1d3e 100644
> --- a/tools/bpf/bpftool/prog.c
> +++ b/tools/bpf/bpftool/prog.c
> @@ -81,6 +81,7 @@ static const char * const attach_type_strings[] = {
> [BPF_SK_SKB_STREAM_PARSER] = "stream_parser",
> [BPF_SK_SKB_STREAM_VERDICT] = "stream_verdict",
> [BPF_SK_MSG_VERDICT] = "msg_verdict",
> + [BPF_FLOW_DISSECTOR] = "flow_dissector",
> [__MAX_BPF_ATTACH_TYPE] = NULL,
> };
>
> @@ -721,30 +722,53 @@ int map_replace_compar(const void *p1, const void *p2)
> return a->idx - b->idx;
> }
>
> -static int do_attach(int argc, char **argv)
> +static int parse_atach_detach_args(int argc, char **argv, int *progfd,
> + enum bpf_attach_type *attach_type,
> + int *mapfd)
> {
> - enum bpf_attach_type attach_type;
> - int err, mapfd, progfd;
> -
> - if (!REQ_ARGS(5)) {
> - p_err("too few parameters for map attach");
> + if (!REQ_ARGS(3)) {
> + p_err("too few parameters for attach/detach");
I know this is not existing bug but we didn't catch it when
attach/ /detach was added :( - REQ_ARGS() already includes a p_err(),
so we would have a duplicate error in JSON. Please drop the error here
and below.
With that fix:
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Thanks for the work!
> return -EINVAL;
> }
>
> - progfd = prog_parse_fd(&argc, &argv);
> - if (progfd < 0)
> - return progfd;
> + *progfd = prog_parse_fd(&argc, &argv);
> + if (*progfd < 0)
> + return *progfd;
>
> - attach_type = parse_attach_type(*argv);
> - if (attach_type == __MAX_BPF_ATTACH_TYPE) {
> - p_err("invalid attach type");
> + *attach_type = parse_attach_type(*argv);
> + if (*attach_type == __MAX_BPF_ATTACH_TYPE) {
> + p_err("invalid attach/detach type");
> return -EINVAL;
> }
> +
> + if (*attach_type == BPF_FLOW_DISSECTOR) {
> + *mapfd = -1;
> + return 0;
> + }
> +
> NEXT_ARG();
> + if (!REQ_ARGS(2)) {
> + p_err("too few parameters for map attach/detach");
> + return -EINVAL;
> + }
>
> - mapfd = map_parse_fd(&argc, &argv);
> - if (mapfd < 0)
> - return mapfd;
> + *mapfd = map_parse_fd(&argc, &argv);
> + if (*mapfd < 0)
> + return *mapfd;
> +
> + return 0;
> +}
> +
^ 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