* HI
From: Mrs Suzara Maling Wan @ 2018-07-23 22:42 UTC (permalink / raw)
--
I am Mrs Suzara i have a pending project of fulfillment to put in your
hand, i will need your support to make this ream come through, could
you le me know your interest to enable me give you further information,
and I hereby advice that you send the below mentioned information I
decided to will/donate the sum of $4.5 Million US to you for the good
work of god, and also to help the motherless and less privilege and
also forth assistance of the widows.
At the moment I cannot take an telephone calls right now due to the
fact that my relatives (that have squandered the funds agave them for
this purpose before) are around me and my health status also. I have
adjusted my will and my lawyer is aware. I have willed those properties
to you by quoting my personal file routing and account information. And
I have also notified the bank that I am willing that properties to you
for a good, effective and prudent\work.
I know I don't know you but I have been directed to do this by god.ok
Please contact this woman for more details you might not get me on line
in time contact this email; mrs.suzaramalingwan1962@gmail.com
Your full name..........
Your private telephone number..........
Your passport or identity card........
Your country....................... ...
Your occupation..............
Thank you as i wait your reply.
Yoursfaithful friand,
Mrs Suzara Maling Wan
^ permalink raw reply
* [PATCH net-next] virtio_net: force_napi_tx module param.
From: Caleb Raitto @ 2018-07-23 23:11 UTC (permalink / raw)
To: mst, jasowang, davem, netdev; +Cc: Caleb Raitto
From: Caleb Raitto <caraitto@google.com>
The driver disables tx napi if it's not certain that completions will
be processed affine with tx service.
Its heuristic doesn't account for some scenarios where it is, such as
when the queue pair count matches the core but not hyperthread count.
Allow userspace to override the heuristic. This is an alternative
solution to that in the linked patch. That added more logic in the
kernel for these cases, but the agreement was that this was better left
to user control.
Do not expand the existing napi_tx variable to a ternary value,
because doing so can break user applications that expect
boolean ('Y'/'N') instead of integer output. Add a new param instead.
Link: https://patchwork.ozlabs.org/patch/725249/
Acked-by: Willem de Bruijn <willemb@google.com>
Acked-by: Jon Olson <jonolson@google.com>
Signed-off-by: Caleb Raitto <caraitto@google.com>
---
drivers/net/virtio_net.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 2ff08bc103a9..d9aca4e90d6b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -39,10 +39,11 @@
static int napi_weight = NAPI_POLL_WEIGHT;
module_param(napi_weight, int, 0444);
-static bool csum = true, gso = true, napi_tx;
+static bool csum = true, gso = true, napi_tx, force_napi_tx;
module_param(csum, bool, 0444);
module_param(gso, bool, 0444);
module_param(napi_tx, bool, 0644);
+module_param(force_napi_tx, bool, 0644);
/* FIXME: MTU in config. */
#define GOOD_PACKET_LEN (ETH_HLEN + VLAN_HLEN + ETH_DATA_LEN)
@@ -1201,7 +1202,7 @@ static void virtnet_napi_tx_enable(struct virtnet_info *vi,
/* Tx napi touches cachelines on the cpu handling tx interrupts. Only
* enable the feature if this is likely affine with the transmit path.
*/
- if (!vi->affinity_hint_set) {
+ if (!vi->affinity_hint_set && !force_napi_tx) {
napi->weight = 0;
return;
}
@@ -2646,7 +2647,7 @@ static int virtnet_alloc_queues(struct virtnet_info *vi)
netif_napi_add(vi->dev, &vi->rq[i].napi, virtnet_poll,
napi_weight);
netif_tx_napi_add(vi->dev, &vi->sq[i].napi, virtnet_poll_tx,
- napi_tx ? napi_weight : 0);
+ (napi_tx || force_napi_tx) ? napi_weight : 0);
sg_init_table(vi->rq[i].sg, ARRAY_SIZE(vi->rq[i].sg));
ewma_pkt_len_init(&vi->rq[i].mrg_avg_pkt_len);
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* Re: [PATCH bpf] bpf: btf: Ensure the member->offset is in the right order
From: Daniel Borkmann @ 2018-07-23 23:22 UTC (permalink / raw)
To: Yonghong Song, Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, kernel-team
In-Reply-To: <0e0a30fe-e1af-681c-2ccd-e9db91d5246f@fb.com>
On 07/23/2018 08:45 PM, Yonghong Song wrote:
> On 7/20/18 5:38 PM, Martin KaFai Lau wrote:
>> This patch ensures the member->offset of a struct
>> is in the correct order (i.e the later member's offset cannot
>> go backward).
>>
>> The current "pahole -J" BTF encoder does not generate something
>> like this. However, checking this can ensure future encoder
>> will not violate this.
>>
>> Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)")
>> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> Acked-by: Yonghong Song <yhs@fb.com>
Applied to bpf, thanks!
^ permalink raw reply
* [PATCH] qmi_wwan: fix interface number for DW5821e production firmware
From: Aleksander Morgado @ 2018-07-23 23:31 UTC (permalink / raw)
To: bjorn; +Cc: davem, netdev, linux-usb, Aleksander Morgado, stable
The original mapping for the DW5821e was done using a development
version of the firmware. Confirmed with the vendor that the final
USB layout ends up exposing the QMI control/data ports in USB
config #1, interface #0, not in interface #1 (which is now a HID
interface).
T: Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
P: Vendor=413c ProdID=81d7 Rev=03.18
S: Manufacturer=DELL
S: Product=DW5821e Snapdragon X20 LTE
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
Fixes: e7e197edd09c25 ("qmi_wwan: add support for the Dell Wireless 5821e module")
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Cc: stable <stable@vger.kernel.org>
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8fac8e132c5b..0ed06d670a5f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1246,7 +1246,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)}, /* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)}, /* Dell Wireless 5811e */
- {QMI_FIXED_INTF(0x413c, 0x81d7, 1)}, /* Dell Wireless 5821e */
+ {QMI_FIXED_INTF(0x413c, 0x81d7, 0)}, /* Dell Wireless 5821e */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)}, /* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module */
{QMI_FIXED_INTF(0x03f0, 0x9d1d, 1)}, /* HP lt4120 Snapdragon X5 LTE */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)}, /* WeTelecom WPD-600N */
--
2.18.0
^ permalink raw reply related
* Re: [patch net-next v4 00/12] sched: introduce chain templates support with offloading to mlxsw
From: Jakub Kicinski @ 2018-07-23 23:36 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, xiyou.wangcong, simon.horman, john.hurley,
dsahern, mlxsw, sridhar.samudrala
In-Reply-To: <20180723072312.4153-1-jiri@resnulli.us>
On Mon, 23 Jul 2018 09:23:03 +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> For the TC clsact offload these days, some of HW drivers need
> to hold a magic ball. The reason is, with the first inserted rule inside
> HW they need to guess what fields will be used for the matching. If
> later on this guess proves to be wrong and user adds a filter with a
> different field to match, there's a problem. Mlxsw resolves it now with
> couple of patterns. Those try to cover as many match fields as possible.
> This aproach is far from optimal, both performance-wise and scale-wise.
> Also, there is a combination of filters that in certain order won't
> succeed.
>
> Most of the time, when user inserts filters in chain, he knows right away
> how the filters are going to look like - what type and option will they
> have. For example, he knows that he will only insert filters of type
> flower matching destination IP address. He can specify a template that
> would cover all the filters in the chain.
>
> This patchset is providing the possibility to user to provide such
> template to kernel and propagate it all the way down to device
> drivers.
LGTM, thanks for the changes!
^ permalink raw reply
* [PATCH net v2] ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull
From: Willem de Bruijn @ 2018-07-23 23:36 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Syzbot reported a read beyond the end of the skb head when returning
IPV6_ORIGDSTADDR:
BUG: KMSAN: kernel-infoleak in put_cmsg+0x5ef/0x860 net/core/scm.c:242
CPU: 0 PID: 4501 Comm: syz-executor128 Not tainted 4.17.0+ #9
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/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1125
kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1219
kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1261
copy_to_user include/linux/uaccess.h:184 [inline]
put_cmsg+0x5ef/0x860 net/core/scm.c:242
ip6_datagram_recv_specific_ctl+0x1cf3/0x1eb0 net/ipv6/datagram.c:719
ip6_datagram_recv_ctl+0x41c/0x450 net/ipv6/datagram.c:733
rawv6_recvmsg+0x10fb/0x1460 net/ipv6/raw.c:521
[..]
This logic and its ipv4 counterpart read the destination port from
the packet at skb_transport_offset(skb) + 4.
With MSG_MORE and a local SOCK_RAW sender, syzbot was able to cook a
packet that stores headers exactly up to skb_transport_offset(skb) in
the head and the remainder in a frag.
Call pskb_may_pull before accessing the pointer to ensure that it lies
in skb head.
Link: http://lkml.kernel.org/r/CAF=yD-LEJwZj5a1-bAAj2Oy_hKmGygV6rsJ_WOrAYnv-fnayiQ@mail.gmail.com
Reported-by: syzbot+9adb4b567003cac781f0@syzkaller.appspotmail.com
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/ipv4/ip_sockglue.c | 7 +++++--
net/ipv6/datagram.c | 7 +++++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 64c76dcf7386..c0fe5ad996f2 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -150,15 +150,18 @@ static void ip_cmsg_recv_dstaddr(struct msghdr *msg, struct sk_buff *skb)
{
struct sockaddr_in sin;
const struct iphdr *iph = ip_hdr(skb);
- __be16 *ports = (__be16 *)skb_transport_header(skb);
+ __be16 *ports;
+ int end;
- if (skb_transport_offset(skb) + 4 > (int)skb->len)
+ end = skb_transport_offset(skb) + 4;
+ if (end > 0 && !pskb_may_pull(skb, end))
return;
/* All current transport protocols have the port numbers in the
* first four bytes of the transport header and this function is
* written with this assumption in mind.
*/
+ ports = (__be16 *)skb_transport_header(skb);
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = iph->daddr;
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 2ee08b6a86a4..1a1f876f8e28 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -700,13 +700,16 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
}
if (np->rxopt.bits.rxorigdstaddr) {
struct sockaddr_in6 sin6;
- __be16 *ports = (__be16 *) skb_transport_header(skb);
+ __be16 *ports;
+ int end;
- if (skb_transport_offset(skb) + 4 <= (int)skb->len) {
+ end = skb_transport_offset(skb) + 4;
+ if (end <= 0 || pskb_may_pull(skb, end)) {
/* All current transport protocols have the port numbers in the
* first four bytes of the transport header and this function is
* written with this assumption in mind.
*/
+ ports = (__be16 *)skb_transport_header(skb);
sin6.sin6_family = AF_INET6;
sin6.sin6_addr = ipv6_hdr(skb)->daddr;
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* [PATCH net-next] cbs: Add support for the graft function
From: Vinicius Costa Gomes @ 2018-07-24 0:08 UTC (permalink / raw)
To: netdev
Cc: Vinicius Costa Gomes, jesus.sanchez-palencia, henrik,
richardcochran, jhs, xiyou.wangcong, jiri, ilias.apalodimas
This will allow to install a child qdisc under cbs. The main use case
is to install ETF (Earliest TxTime First) qdisc under cbs, so there's
another level of control for time-sensitive traffic.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
---
net/sched/sch_cbs.c | 134 +++++++++++++++++++++++++++++++++++++++++---
1 file changed, 125 insertions(+), 9 deletions(-)
diff --git a/net/sched/sch_cbs.c b/net/sched/sch_cbs.c
index cdd96b9a27bc..e26a24017faa 100644
--- a/net/sched/sch_cbs.c
+++ b/net/sched/sch_cbs.c
@@ -78,18 +78,42 @@ struct cbs_sched_data {
s64 sendslope; /* in bytes/s */
s64 idleslope; /* in bytes/s */
struct qdisc_watchdog watchdog;
- int (*enqueue)(struct sk_buff *skb, struct Qdisc *sch);
+ int (*enqueue)(struct sk_buff *skb, struct Qdisc *sch,
+ struct sk_buff **to_free);
struct sk_buff *(*dequeue)(struct Qdisc *sch);
+ struct Qdisc *qdisc;
};
-static int cbs_enqueue_offload(struct sk_buff *skb, struct Qdisc *sch)
+static int cbs_child_enqueue(struct sk_buff *skb, struct Qdisc *sch,
+ struct Qdisc *child,
+ struct sk_buff **to_free)
{
- return qdisc_enqueue_tail(skb, sch);
+ int err;
+
+ err = child->ops->enqueue(skb, child, to_free);
+ if (err != NET_XMIT_SUCCESS)
+ return err;
+
+ qdisc_qstats_backlog_inc(sch, skb);
+ sch->q.qlen++;
+
+ return NET_XMIT_SUCCESS;
}
-static int cbs_enqueue_soft(struct sk_buff *skb, struct Qdisc *sch)
+static int cbs_enqueue_offload(struct sk_buff *skb, struct Qdisc *sch,
+ struct sk_buff **to_free)
{
struct cbs_sched_data *q = qdisc_priv(sch);
+ struct Qdisc *qdisc = q->qdisc;
+
+ return cbs_child_enqueue(skb, sch, qdisc, to_free);
+}
+
+static int cbs_enqueue_soft(struct sk_buff *skb, struct Qdisc *sch,
+ struct sk_buff **to_free)
+{
+ struct cbs_sched_data *q = qdisc_priv(sch);
+ struct Qdisc *qdisc = q->qdisc;
if (sch->q.qlen == 0 && q->credits > 0) {
/* We need to stop accumulating credits when there's
@@ -99,7 +123,7 @@ static int cbs_enqueue_soft(struct sk_buff *skb, struct Qdisc *sch)
q->last = ktime_get_ns();
}
- return qdisc_enqueue_tail(skb, sch);
+ return cbs_child_enqueue(skb, sch, qdisc, to_free);
}
static int cbs_enqueue(struct sk_buff *skb, struct Qdisc *sch,
@@ -107,7 +131,7 @@ static int cbs_enqueue(struct sk_buff *skb, struct Qdisc *sch,
{
struct cbs_sched_data *q = qdisc_priv(sch);
- return q->enqueue(skb, sch);
+ return q->enqueue(skb, sch, to_free);
}
/* timediff is in ns, slope is in bytes/s */
@@ -132,9 +156,25 @@ static s64 credits_from_len(unsigned int len, s64 slope, s64 port_rate)
return div64_s64(len * slope, port_rate);
}
+static struct sk_buff *cbs_child_dequeue(struct Qdisc *sch, struct Qdisc *child)
+{
+ struct sk_buff *skb;
+
+ skb = child->ops->dequeue(child);
+ if (!skb)
+ return NULL;
+
+ qdisc_qstats_backlog_dec(sch, skb);
+ qdisc_bstats_update(sch, skb);
+ sch->q.qlen--;
+
+ return skb;
+}
+
static struct sk_buff *cbs_dequeue_soft(struct Qdisc *sch)
{
struct cbs_sched_data *q = qdisc_priv(sch);
+ struct Qdisc *qdisc = q->qdisc;
s64 now = ktime_get_ns();
struct sk_buff *skb;
s64 credits;
@@ -157,8 +197,7 @@ static struct sk_buff *cbs_dequeue_soft(struct Qdisc *sch)
return NULL;
}
}
-
- skb = qdisc_dequeue_head(sch);
+ skb = cbs_child_dequeue(sch, qdisc);
if (!skb)
return NULL;
@@ -178,7 +217,10 @@ static struct sk_buff *cbs_dequeue_soft(struct Qdisc *sch)
static struct sk_buff *cbs_dequeue_offload(struct Qdisc *sch)
{
- return qdisc_dequeue_head(sch);
+ struct cbs_sched_data *q = qdisc_priv(sch);
+ struct Qdisc *qdisc = q->qdisc;
+
+ return cbs_child_dequeue(sch, qdisc);
}
static struct sk_buff *cbs_dequeue(struct Qdisc *sch)
@@ -310,6 +352,13 @@ static int cbs_init(struct Qdisc *sch, struct nlattr *opt,
return -EINVAL;
}
+ q->qdisc = qdisc_create_dflt(sch->dev_queue, &pfifo_qdisc_ops,
+ sch->handle, extack);
+ if (!q->qdisc)
+ return -ENOMEM;
+
+ qdisc_hash_add(q->qdisc, false);
+
q->queue = sch->dev_queue - netdev_get_tx_queue(dev, 0);
q->enqueue = cbs_enqueue_soft;
@@ -328,6 +377,9 @@ static void cbs_destroy(struct Qdisc *sch)
qdisc_watchdog_cancel(&q->watchdog);
cbs_disable_offload(dev, q);
+
+ if (q->qdisc)
+ qdisc_destroy(q->qdisc);
}
static int cbs_dump(struct Qdisc *sch, struct sk_buff *skb)
@@ -356,8 +408,72 @@ static int cbs_dump(struct Qdisc *sch, struct sk_buff *skb)
return -1;
}
+static int cbs_dump_class(struct Qdisc *sch, unsigned long cl,
+ struct sk_buff *skb, struct tcmsg *tcm)
+{
+ struct cbs_sched_data *q = qdisc_priv(sch);
+
+ if (cl != 1 || !q->qdisc) /* only one class */
+ return -ENOENT;
+
+ tcm->tcm_handle |= TC_H_MIN(1);
+ tcm->tcm_info = q->qdisc->handle;
+
+ return 0;
+}
+
+static int cbs_graft(struct Qdisc *sch, unsigned long arg, struct Qdisc *new,
+ struct Qdisc **old, struct netlink_ext_ack *extack)
+{
+ struct cbs_sched_data *q = qdisc_priv(sch);
+
+ if (!new) {
+ new = qdisc_create_dflt(sch->dev_queue, &pfifo_qdisc_ops,
+ sch->handle, NULL);
+ if (!new)
+ new = &noop_qdisc;
+ }
+
+ *old = qdisc_replace(sch, new, &q->qdisc);
+ return 0;
+}
+
+static struct Qdisc *cbs_leaf(struct Qdisc *sch, unsigned long arg)
+{
+ struct cbs_sched_data *q = qdisc_priv(sch);
+
+ return q->qdisc;
+}
+
+static unsigned long cbs_find(struct Qdisc *sch, u32 classid)
+{
+ return 1;
+}
+
+static void cbs_walk(struct Qdisc *sch, struct qdisc_walker *walker)
+{
+ if (!walker->stop) {
+ if (walker->count >= walker->skip) {
+ if (walker->fn(sch, 1, walker) < 0) {
+ walker->stop = 1;
+ return;
+ }
+ }
+ walker->count++;
+ }
+}
+
+static const struct Qdisc_class_ops cbs_class_ops = {
+ .graft = cbs_graft,
+ .leaf = cbs_leaf,
+ .find = cbs_find,
+ .walk = cbs_walk,
+ .dump = cbs_dump_class,
+};
+
static struct Qdisc_ops cbs_qdisc_ops __read_mostly = {
.id = "cbs",
+ .cl_ops = &cbs_class_ops,
.priv_size = sizeof(struct cbs_sched_data),
.enqueue = cbs_enqueue,
.dequeue = cbs_dequeue,
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 1/4] MIPS: lantiq: Do not enable IRQs in dma open
From: Paul Burton @ 2018-07-24 0:19 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: davem, netdev, andrew, vivien.didelot, f.fainelli, john,
linux-mips, dev, hauke.mehrtens
In-Reply-To: <20180721191358.13952-2-hauke@hauke-m.de>
Hi Hauke,
On Sat, Jul 21, 2018 at 09:13:55PM +0200, Hauke Mehrtens wrote:
> When a DMA channel is opened the IRQ should not get activated
> automatically, this allows it to pull data out manually without the help
> of interrupts. This is needed for a workaround in the vrx200 Ethernet
> driver.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
> arch/mips/lantiq/xway/dma.c | 1 -
> drivers/net/ethernet/lantiq_etop.c | 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
If you'd like this to go via the netdev tree to keep it with the rest of
the series:
Acked-by: Paul Burton <paul.burton@mips.com>
Though I'd be happier if we didn't have DMA code seemingly used only by
an ethernet driver in arch/mips/ :)
Thanks,
Paul
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: kbuild test robot @ 2018-07-24 0:19 UTC (permalink / raw)
To: Toshiaki Makita
Cc: kbuild-all, netdev, Alexei Starovoitov, Daniel Borkmann,
Toshiaki Makita, Jesper Dangaard Brouer
In-Reply-To: <20180722151308.5480-6-toshiaki.makita1@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]
Hi Toshiaki,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Toshiaki-Makita/veth-Driver-XDP/20180724-065517
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-randconfig-x001-201829 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/timer.h:5,
from include/linux/netdevice.h:28,
from drivers//net/veth.c:11:
drivers//net/veth.c: In function 'veth_xdp_xmit':
>> drivers//net/veth.c:300:16: error: implicit declaration of function 'xdp_ok_fwd_dev' [-Werror=implicit-function-declaration]
if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
^
include/linux/compiler.h:77:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
cc1: some warnings being treated as errors
vim +/xdp_ok_fwd_dev +300 drivers//net/veth.c
275
276 static int veth_xdp_xmit(struct net_device *dev, int n,
277 struct xdp_frame **frames, u32 flags)
278 {
279 struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
280 struct net_device *rcv;
281 int i, drops = 0;
282
283 if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
284 return -EINVAL;
285
286 rcv = rcu_dereference(priv->peer);
287 if (unlikely(!rcv))
288 return -ENXIO;
289
290 rcv_priv = netdev_priv(rcv);
291 /* xdp_ring is initialized on receive side? */
292 if (!rcu_access_pointer(rcv_priv->xdp_prog))
293 return -ENXIO;
294
295 spin_lock(&rcv_priv->xdp_ring.producer_lock);
296 for (i = 0; i < n; i++) {
297 struct xdp_frame *frame = frames[i];
298 void *ptr = veth_xdp_to_ptr(frame);
299
> 300 if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
301 __ptr_ring_produce(&rcv_priv->xdp_ring, ptr))) {
302 xdp_return_frame_rx_napi(frame);
303 drops++;
304 }
305 }
306 spin_unlock(&rcv_priv->xdp_ring.producer_lock);
307
308 if (flags & XDP_XMIT_FLUSH)
309 __veth_xdp_flush(rcv_priv);
310
311 return n - drops;
312 }
313
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34669 bytes --]
^ permalink raw reply
* [PATCH v3] hv_netvsc: Add per-cpu ethtool stats for netvsc
From: Yidong Ren @ 2018-07-24 1:26 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
David S. Miller, devel, netdev, linux-kernel
Cc: madhans
In-Reply-To: <20180613193608.444-1-yidren@linuxonhyperv.com>
From: Yidong Ren <yidren@microsoft.com>
This patch implements following ethtool stats fields for netvsc:
cpu<n>_tx/rx_packets/bytes
cpu<n>_vf_tx/rx_packets/bytes
Corresponding per-cpu counters already exist in current code. Exposing
these counters will help troubleshooting performance issues.
Signed-off-by: Yidong Ren <yidren@microsoft.com>
---
Changes since v2:
* Reimplemented with kvmalloc instead of alloc_percpu
drivers/net/hyperv/hyperv_net.h | 11 ++++
drivers/net/hyperv/netvsc_drv.c | 103 +++++++++++++++++++++++++++++++-
2 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 4b6e308199d2..a32ded5b4f41 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -873,6 +873,17 @@ struct netvsc_ethtool_stats {
unsigned long wake_queue;
};
+struct netvsc_ethtool_pcpu_stats {
+ u64 rx_packets;
+ u64 rx_bytes;
+ u64 tx_packets;
+ u64 tx_bytes;
+ u64 vf_rx_packets;
+ u64 vf_rx_bytes;
+ u64 vf_tx_packets;
+ u64 vf_tx_bytes;
+};
+
struct netvsc_vf_pcpu_stats {
u64 rx_packets;
u64 rx_bytes;
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index dd1d6e115145..51f9cab2da5b 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1118,6 +1118,64 @@ static void netvsc_get_vf_stats(struct net_device *net,
}
}
+static void netvsc_get_pcpu_stats(struct net_device *net,
+ struct netvsc_ethtool_pcpu_stats *pcpu_tot)
+{
+ struct net_device_context *ndev_ctx = netdev_priv(net);
+ struct netvsc_device *nvdev = rcu_dereference_rtnl(ndev_ctx->nvdev);
+ int i;
+
+ /* fetch percpu stats of vf */
+ for_each_possible_cpu(i) {
+ const struct netvsc_vf_pcpu_stats *stats =
+ per_cpu_ptr(ndev_ctx->vf_stats, i);
+ struct netvsc_ethtool_pcpu_stats *this_tot = &pcpu_tot[i];
+ unsigned int start;
+
+ do {
+ start = u64_stats_fetch_begin_irq(&stats->syncp);
+ this_tot->vf_rx_packets = stats->rx_packets;
+ this_tot->vf_tx_packets = stats->tx_packets;
+ this_tot->vf_rx_bytes = stats->rx_bytes;
+ this_tot->vf_tx_bytes = stats->tx_bytes;
+ } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
+ this_tot->rx_packets = this_tot->vf_rx_packets;
+ this_tot->tx_packets = this_tot->vf_tx_packets;
+ this_tot->rx_bytes = this_tot->vf_rx_bytes;
+ this_tot->tx_bytes = this_tot->vf_tx_bytes;
+ }
+
+ /* fetch percpu stats of netvsc */
+ for (i = 0; i < nvdev->num_chn; i++) {
+ const struct netvsc_channel *nvchan = &nvdev->chan_table[i];
+ const struct netvsc_stats *stats;
+ struct netvsc_ethtool_pcpu_stats *this_tot =
+ &pcpu_tot[nvchan->channel->target_cpu];
+ u64 packets, bytes;
+ unsigned int start;
+
+ stats = &nvchan->tx_stats;
+ do {
+ start = u64_stats_fetch_begin_irq(&stats->syncp);
+ packets = stats->packets;
+ bytes = stats->bytes;
+ } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
+
+ this_tot->tx_bytes += bytes;
+ this_tot->tx_packets += packets;
+
+ stats = &nvchan->rx_stats;
+ do {
+ start = u64_stats_fetch_begin_irq(&stats->syncp);
+ packets = stats->packets;
+ bytes = stats->bytes;
+ } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
+
+ this_tot->rx_bytes += bytes;
+ this_tot->rx_packets += packets;
+ }
+}
+
static void netvsc_get_stats64(struct net_device *net,
struct rtnl_link_stats64 *t)
{
@@ -1215,6 +1273,23 @@ static const struct {
{ "rx_no_memory", offsetof(struct netvsc_ethtool_stats, rx_no_memory) },
{ "stop_queue", offsetof(struct netvsc_ethtool_stats, stop_queue) },
{ "wake_queue", offsetof(struct netvsc_ethtool_stats, wake_queue) },
+}, pcpu_stats[] = {
+ { "cpu%u_rx_packets",
+ offsetof(struct netvsc_ethtool_pcpu_stats, rx_packets) },
+ { "cpu%u_rx_bytes",
+ offsetof(struct netvsc_ethtool_pcpu_stats, rx_bytes) },
+ { "cpu%u_tx_packets",
+ offsetof(struct netvsc_ethtool_pcpu_stats, tx_packets) },
+ { "cpu%u_tx_bytes",
+ offsetof(struct netvsc_ethtool_pcpu_stats, tx_bytes) },
+ { "cpu%u_vf_rx_packets",
+ offsetof(struct netvsc_ethtool_pcpu_stats, vf_rx_packets) },
+ { "cpu%u_vf_rx_bytes",
+ offsetof(struct netvsc_ethtool_pcpu_stats, vf_rx_bytes) },
+ { "cpu%u_vf_tx_packets",
+ offsetof(struct netvsc_ethtool_pcpu_stats, vf_tx_packets) },
+ { "cpu%u_vf_tx_bytes",
+ offsetof(struct netvsc_ethtool_pcpu_stats, vf_tx_bytes) },
}, vf_stats[] = {
{ "vf_rx_packets", offsetof(struct netvsc_vf_pcpu_stats, rx_packets) },
{ "vf_rx_bytes", offsetof(struct netvsc_vf_pcpu_stats, rx_bytes) },
@@ -1226,6 +1301,9 @@ static const struct {
#define NETVSC_GLOBAL_STATS_LEN ARRAY_SIZE(netvsc_stats)
#define NETVSC_VF_STATS_LEN ARRAY_SIZE(vf_stats)
+/* statistics per queue (rx/tx packets/bytes) */
+#define NETVSC_PCPU_STATS_LEN (num_present_cpus() * ARRAY_SIZE(pcpu_stats))
+
/* 4 statistics per queue (rx/tx packets/bytes) */
#define NETVSC_QUEUE_STATS_LEN(dev) ((dev)->num_chn * 4)
@@ -1241,6 +1319,7 @@ static int netvsc_get_sset_count(struct net_device *dev, int string_set)
case ETH_SS_STATS:
return NETVSC_GLOBAL_STATS_LEN
+ NETVSC_VF_STATS_LEN
+ + NETVSC_PCPU_STATS_LEN
+ NETVSC_QUEUE_STATS_LEN(nvdev);
default:
return -EINVAL;
@@ -1255,9 +1334,10 @@ static void netvsc_get_ethtool_stats(struct net_device *dev,
const void *nds = &ndc->eth_stats;
const struct netvsc_stats *qstats;
struct netvsc_vf_pcpu_stats sum;
+ struct netvsc_ethtool_pcpu_stats *pcpu_sum;
unsigned int start;
u64 packets, bytes;
- int i, j;
+ int i, j, cpu;
if (!nvdev)
return;
@@ -1269,6 +1349,18 @@ static void netvsc_get_ethtool_stats(struct net_device *dev,
for (j = 0; j < NETVSC_VF_STATS_LEN; j++)
data[i++] = *(u64 *)((void *)&sum + vf_stats[j].offset);
+ pcpu_sum = kvmalloc(sizeof(struct netvsc_ethtool_pcpu_stats) *
+ num_present_cpus(), GFP_KERNEL);
+ netvsc_get_pcpu_stats(dev, pcpu_sum);
+ for_each_present_cpu(cpu) {
+ struct netvsc_ethtool_pcpu_stats *this_sum = &pcpu_sum[cpu];
+
+ for (j = 0; j < ARRAY_SIZE(pcpu_stats); j++)
+ data[i++] = *(u64 *)((void *)this_sum
+ + pcpu_stats[j].offset);
+ }
+ kvfree(pcpu_sum);
+
for (j = 0; j < nvdev->num_chn; j++) {
qstats = &nvdev->chan_table[j].tx_stats;
@@ -1296,7 +1388,7 @@ static void netvsc_get_strings(struct net_device *dev, u32 stringset, u8 *data)
struct net_device_context *ndc = netdev_priv(dev);
struct netvsc_device *nvdev = rtnl_dereference(ndc->nvdev);
u8 *p = data;
- int i;
+ int i, cpu;
if (!nvdev)
return;
@@ -1313,6 +1405,13 @@ static void netvsc_get_strings(struct net_device *dev, u32 stringset, u8 *data)
p += ETH_GSTRING_LEN;
}
+ for_each_present_cpu(cpu) {
+ for (i = 0; i < ARRAY_SIZE(pcpu_stats); i++) {
+ sprintf(p, pcpu_stats[i].name, cpu);
+ p += ETH_GSTRING_LEN;
+ }
+ }
+
for (i = 0; i < nvdev->num_chn; i++) {
sprintf(p, "tx_queue_%u_packets", i);
p += ETH_GSTRING_LEN;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 bpf-next 2/8] veth: Add driver XDP
From: Jakub Kicinski @ 2018-07-24 0:23 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
Jesper Dangaard Brouer
In-Reply-To: <20180722151308.5480-3-toshiaki.makita1@gmail.com>
On Mon, 23 Jul 2018 00:13:02 +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> This is the basic implementation of veth driver XDP.
>
> Incoming packets are sent from the peer veth device in the form of skb,
> so this is generally doing the same thing as generic XDP.
>
> This itself is not so useful, but a starting point to implement other
> useful veth XDP features like TX and REDIRECT.
>
> This introduces NAPI when XDP is enabled, because XDP is now heavily
> relies on NAPI context. Use ptr_ring to emulate NIC ring. Tx function
> enqueues packets to the ring and peer NAPI handler drains the ring.
>
> Currently only one ring is allocated for each veth device, so it does
> not scale on multiqueue env. This can be resolved by allocating rings
> on the per-queue basis later.
>
> Note that NAPI is not used but netif_rx is used when XDP is not loaded,
> so this does not change the default behaviour.
>
> v3:
> - Fix race on closing the device.
> - Add extack messages in ndo_bpf.
>
> v2:
> - Squashed with the patch adding NAPI.
> - Implement adjust_tail.
> - Don't acquire consumer lock because it is guarded by NAPI.
> - Make poll_controller noop since it is unnecessary.
> - Register rxq_info on enabling XDP rather than on opening the device.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> +static struct sk_buff *veth_xdp_rcv_skb(struct veth_priv *priv,
> + struct sk_buff *skb)
> +{
> + u32 pktlen, headroom, act, metalen;
> + void *orig_data, *orig_data_end;
> + int size, mac_len, delta, off;
> + struct bpf_prog *xdp_prog;
> + struct xdp_buff xdp;
> +
> + rcu_read_lock();
> + xdp_prog = rcu_dereference(priv->xdp_prog);
> + if (unlikely(!xdp_prog)) {
> + rcu_read_unlock();
> + goto out;
> + }
> +
> + mac_len = skb->data - skb_mac_header(skb);
> + pktlen = skb->len + mac_len;
> + size = SKB_DATA_ALIGN(VETH_XDP_HEADROOM + pktlen) +
> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> + if (size > PAGE_SIZE)
> + goto drop;
> +
> + headroom = skb_headroom(skb) - mac_len;
> + if (skb_shared(skb) || skb_head_is_locked(skb) ||
> + skb_is_nonlinear(skb) || headroom < XDP_PACKET_HEADROOM) {
> + struct sk_buff *nskb;
> + void *head, *start;
> + struct page *page;
> + int head_off;
> +
> + page = alloc_page(GFP_ATOMIC);
> + if (!page)
> + goto drop;
> +
> + head = page_address(page);
> + start = head + VETH_XDP_HEADROOM;
> + if (skb_copy_bits(skb, -mac_len, start, pktlen)) {
> + page_frag_free(head);
> + goto drop;
> + }
> +
> + nskb = veth_build_skb(head,
> + VETH_XDP_HEADROOM + mac_len, skb->len,
> + PAGE_SIZE);
> + if (!nskb) {
> + page_frag_free(head);
> + goto drop;
> + }
> +static int veth_enable_xdp(struct net_device *dev)
> +{
> + struct veth_priv *priv = netdev_priv(dev);
> + int err;
> +
> + if (!xdp_rxq_info_is_reg(&priv->xdp_rxq)) {
> + err = xdp_rxq_info_reg(&priv->xdp_rxq, dev, 0);
> + if (err < 0)
> + return err;
> +
> + err = xdp_rxq_info_reg_mem_model(&priv->xdp_rxq,
> + MEM_TYPE_PAGE_SHARED, NULL);
nit: doesn't matter much but looks like a mix of MEM_TYPE_PAGE_SHARED
and MEM_TYPE_PAGE_ORDER0
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/8] veth: Avoid drops by oversized packets when XDP is enabled
From: Jakub Kicinski @ 2018-07-24 0:27 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
Jesper Dangaard Brouer
In-Reply-To: <20180722151308.5480-4-toshiaki.makita1@gmail.com>
On Mon, 23 Jul 2018 00:13:03 +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> All oversized packets including GSO packets are dropped if XDP is
> enabled on receiver side, so don't send such packets from peer.
>
> Drop TSO and SCTP fragmentation features so that veth devices themselves
> segment packets with XDP enabled. Also cap MTU accordingly.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Is there any precedence for fixing up features and MTU like this? Most
drivers just refuse to install the program if settings are incompatible.
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 78fa08cb6e24..f5b72e937d9d 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -542,6 +542,23 @@ static int veth_get_iflink(const struct net_device *dev)
> return iflink;
> }
>
> +static netdev_features_t veth_fix_features(struct net_device *dev,
> + netdev_features_t features)
> +{
> + struct veth_priv *priv = netdev_priv(dev);
> + struct net_device *peer;
> +
> + peer = rtnl_dereference(priv->peer);
> + if (peer) {
> + struct veth_priv *peer_priv = netdev_priv(peer);
> +
> + if (peer_priv->_xdp_prog)
> + features &= ~NETIF_F_GSO_SOFTWARE;
> + }
> +
> + return features;
> +}
> +
> static void veth_set_rx_headroom(struct net_device *dev, int new_hr)
> {
> struct veth_priv *peer_priv, *priv = netdev_priv(dev);
> @@ -591,14 +608,33 @@ static int veth_xdp_set(struct net_device *dev, struct bpf_prog *prog,
> goto err;
> }
> }
> +
> + if (!old_prog) {
> + peer->hw_features &= ~NETIF_F_GSO_SOFTWARE;
> + peer->max_mtu = PAGE_SIZE - VETH_XDP_HEADROOM -
> + peer->hard_header_len -
> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> + if (peer->mtu > peer->max_mtu)
> + dev_set_mtu(peer, peer->max_mtu);
> + }
> }
>
> if (old_prog) {
> - if (!prog && dev->flags & IFF_UP)
> - veth_disable_xdp(dev);
> + if (!prog) {
> + if (dev->flags & IFF_UP)
> + veth_disable_xdp(dev);
> +
> + if (peer) {
> + peer->hw_features |= NETIF_F_GSO_SOFTWARE;
> + peer->max_mtu = ETH_MAX_MTU;
> + }
> + }
> bpf_prog_put(old_prog);
> }
>
> + if ((!!old_prog ^ !!prog) && peer)
> + netdev_update_features(peer);
> +
> return 0;
> err:
> priv->_xdp_prog = old_prog;
> @@ -643,6 +679,7 @@ static const struct net_device_ops veth_netdev_ops = {
> .ndo_poll_controller = veth_poll_controller,
> #endif
> .ndo_get_iflink = veth_get_iflink,
> + .ndo_fix_features = veth_fix_features,
> .ndo_features_check = passthru_features_check,
> .ndo_set_rx_headroom = veth_set_rx_headroom,
> .ndo_bpf = veth_xdp,
^ permalink raw reply
* Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver
From: Paul Burton @ 2018-07-24 0:34 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: davem, netdev, andrew, vivien.didelot, f.fainelli, john,
linux-mips, dev, hauke.mehrtens
In-Reply-To: <20180721191358.13952-4-hauke@hauke-m.de>
Hi Hauke,
On Sat, Jul 21, 2018 at 09:13:57PM +0200, Hauke Mehrtens wrote:
> diff --git a/arch/mips/lantiq/xway/sysctrl.c b/arch/mips/lantiq/xway/sysctrl.c
> index e0af39b33e28..c704312ef7d5 100644
> --- a/arch/mips/lantiq/xway/sysctrl.c
> +++ b/arch/mips/lantiq/xway/sysctrl.c
> @@ -536,7 +536,7 @@ void __init ltq_soc_init(void)
> clkdev_add_pmu(NULL, "ahb", 1, 0, PMU_AHBM | PMU_AHBS);
>
> clkdev_add_pmu("1da00000.usif", "NULL", 1, 0, PMU_USIF);
> - clkdev_add_pmu("1e108000.eth", NULL, 0, 0,
> + clkdev_add_pmu("1e10b308.eth", NULL, 0, 0,
> PMU_SWITCH | PMU_PPE_DPLUS | PMU_PPE_DPLUM |
> PMU_PPE_EMA | PMU_PPE_TC | PMU_PPE_SLL01 |
> PMU_PPE_QSB | PMU_PPE_TOP);
Is this intentional?
Why is it needed? Was the old address wrong? Does it change anything
functionally?
If it is needed it seems like a separate change - unless there's some
reason it's tied to adding this driver?
Should this really apply only to the lantiq,vr9 case or also to the
similar lantiq,grx390 & lantiq,ar10 paths?
Whatever the answers to these questions it would be good to include them
in the commit message.
Thanks,
Paul
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: kbuild test robot @ 2018-07-24 0:33 UTC (permalink / raw)
To: Toshiaki Makita
Cc: kbuild-all, netdev, Alexei Starovoitov, Daniel Borkmann,
Toshiaki Makita, Jesper Dangaard Brouer
In-Reply-To: <20180722151308.5480-6-toshiaki.makita1@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]
Hi Toshiaki,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Toshiaki-Makita/veth-Driver-XDP/20180724-065517
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: x86_64-randconfig-x010-201829 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/timer.h:5,
from include/linux/netdevice.h:28,
from drivers//net/veth.c:11:
drivers//net/veth.c: In function 'veth_xdp_xmit':
drivers//net/veth.c:300:16: error: implicit declaration of function 'xdp_ok_fwd_dev' [-Werror=implicit-function-declaration]
if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//net/veth.c:300:3: note: in expansion of macro 'if'
if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
^~
include/linux/compiler.h:48:24: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__branch_check__(x, 0, __builtin_constant_p(x)))
^~~~~~~~~~~~~~~~
>> drivers//net/veth.c:300:7: note: in expansion of macro 'unlikely'
if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
^~~~~~~~
cc1: some warnings being treated as errors
vim +/if +300 drivers//net/veth.c
275
276 static int veth_xdp_xmit(struct net_device *dev, int n,
277 struct xdp_frame **frames, u32 flags)
278 {
279 struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
280 struct net_device *rcv;
281 int i, drops = 0;
282
283 if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
284 return -EINVAL;
285
286 rcv = rcu_dereference(priv->peer);
287 if (unlikely(!rcv))
288 return -ENXIO;
289
290 rcv_priv = netdev_priv(rcv);
291 /* xdp_ring is initialized on receive side? */
292 if (!rcu_access_pointer(rcv_priv->xdp_prog))
293 return -ENXIO;
294
295 spin_lock(&rcv_priv->xdp_ring.producer_lock);
296 for (i = 0; i < n; i++) {
297 struct xdp_frame *frame = frames[i];
298 void *ptr = veth_xdp_to_ptr(frame);
299
> 300 if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
301 __ptr_ring_produce(&rcv_priv->xdp_ring, ptr))) {
302 xdp_return_frame_rx_napi(frame);
303 drops++;
304 }
305 }
306 spin_unlock(&rcv_priv->xdp_ring.producer_lock);
307
308 if (flags & XDP_XMIT_FLUSH)
309 __veth_xdp_flush(rcv_priv);
310
311 return n - drops;
312 }
313
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 31379 bytes --]
^ permalink raw reply
* Re: [PATCH] net/p9/trans_fd.c: fix double list_del()
From: jiangyiwen @ 2018-07-24 1:40 UTC (permalink / raw)
To: Tomas Bortoli, ericvh, rminnich, lucho
Cc: asmadeus, davem, v9fs-developer, netdev, linux-kernel, syzkaller
In-Reply-To: <20180723121902.20201-1-tomasbortoli@gmail.com>
On 2018/7/23 20:19, Tomas Bortoli wrote:
> A double list_del(&req->req_list) is possible in p9_fd_cancel() as
> shown by Syzbot. To prevent it we have to ensure that we have the
> client->lock when deleting the list. Furthermore, we have to update
> the status of the request before releasing the lock, to prevent the
> race.
>
> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
> Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
> ---
> net/9p/trans_fd.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
> index a64b01c56e30..370c6c69a05c 100644
> --- a/net/9p/trans_fd.c
> +++ b/net/9p/trans_fd.c
> @@ -199,15 +199,14 @@ static void p9_mux_poll_stop(struct p9_conn *m)
> static void p9_conn_cancel(struct p9_conn *m, int err)
> {
> struct p9_req_t *req, *rtmp;
> - unsigned long flags;
> LIST_HEAD(cancel_list);
>
> p9_debug(P9_DEBUG_ERROR, "mux %p err %d\n", m, err);
>
> - spin_lock_irqsave(&m->client->lock, flags);
> + spin_lock(&m->client->lock);
>
> if (m->err) {
> - spin_unlock_irqrestore(&m->client->lock, flags);
> + spin_unlock(&m->client->lock);
> return;
> }
>
> @@ -219,7 +218,6 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
> list_for_each_entry_safe(req, rtmp, &m->unsent_req_list, req_list) {
> list_move(&req->req_list, &cancel_list);
> }
> - spin_unlock_irqrestore(&m->client->lock, flags);
>
> list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
> p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
> @@ -228,6 +226,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
> req->t_err = err;
> p9_client_cb(m->client, req, REQ_STATUS_ERROR);
> }
> + spin_unlock(&m->client->lock);
If you want to expand the ranges of client->lock, the cancel_list will not
be necessary, you can optimize this code.
Thanks,
Yiwen.
> }
>
> static __poll_t
> @@ -370,12 +369,12 @@ static void p9_read_work(struct work_struct *work)
> if (m->req->status != REQ_STATUS_ERROR)
> status = REQ_STATUS_RCVD;
> list_del(&m->req->req_list);
> - spin_unlock(&m->client->lock);
> p9_client_cb(m->client, m->req, status);
> m->rc.sdata = NULL;
> m->rc.offset = 0;
> m->rc.capacity = 0;
> m->req = NULL;
> + spin_unlock(&m->client->lock);
> }
>
> end_clear:
>
^ permalink raw reply
* RE: [PATCH v3] hv_netvsc: Add per-cpu ethtool stats for netvsc
From: Yidong Ren @ 2018-07-24 1:42 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger, David S. Miller,
devel@linuxdriverproject.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Madhan Sivakumar
In-Reply-To: <20180724012622.26873-1-yidren@linuxonhyperv.com>
> From: Yidong Ren <yidren@linuxonhyperv.com>
> Sent: Monday, July 23, 2018 6:26 PM
> + pcpu_sum = kvmalloc(sizeof(struct netvsc_ethtool_pcpu_stats) *
> + num_present_cpus(), GFP_KERNEL);
Since there is no plan for CPU hotplug in Hyper-V in short term, it is fine
to use num_present_cpus for now. We can move to debugfs later if necessary.
^ permalink raw reply
* [PATCH net-next] tcp: ack immediately when a cwr packet arrives
From: Lawrence Brakmo @ 2018-07-24 0:49 UTC (permalink / raw)
To: netdev
Cc: Kernel Team, Alexei Starovoitov, Neal Cardwell, Yuchung Cheng,
Eric Dumazet
We observed high 99 and 99.9% latencies when doing RPCs with DCTCP. The
problem is triggered when the last packet of a request arrives CE
marked. The reply will carry the ECE mark causing TCP to shrink its cwnd
to 1 (because there are no packets in flight). When the 1st packet of
the next request arrives, the ACK was sometimes delayed even though it
is CWR marked, adding up to 40ms to the RPC latency.
This patch insures that CWR marked data packets arriving will be acked
immediately.
Packetdrill script to reproduce the problem:
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 setsockopt(3, SOL_TCP, TCP_CONGESTION, "dctcp", 5) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0
0.100 < [ect0] SEW 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
0.100 > SE. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
0.110 < [ect0] . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4
0.200 < [ect0] . 1:1001(1000) ack 1 win 257
0.200 > [ect01] . 1:1(0) ack 1001
0.200 write(4, ..., 1) = 1
0.200 > [ect01] P. 1:2(1) ack 1001
0.200 < [ect0] . 1001:2001(1000) ack 2 win 257
0.200 write(4, ..., 1) = 1
0.200 > [ect01] P. 2:3(1) ack 2001
0.200 < [ect0] . 2001:3001(1000) ack 3 win 257
0.200 < [ect0] . 3001:4001(1000) ack 3 win 257
0.200 > [ect01] . 3:3(0) ack 4001
0.210 < [ce] P. 4001:4501(500) ack 3 win 257
+0.001 read(4, ..., 4500) = 4500
+0 write(4, ..., 1) = 1
+0 > [ect01] PE. 3:4(1) ack 4501
+0.010 < [ect0] W. 4501:5501(1000) ack 4 win 257
// Previously the ACK sequence below would be 4501, causing a long RTO
+0.040~+0.045 > [ect01] . 4:4(0) ack 5501 // delayed ack
+0.311 < [ect0] . 5501:6501(1000) ack 4 win 257 // More data
+0 > [ect01] . 4:4(0) ack 6501 // now acks everything
+0.500 < F. 9501:9501(0) ack 4 win 257
Modified based on comments by Neal Cardwell <ncardwell@google.com>
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
---
net/ipv4/tcp_input.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 91dbb9afb950..2370fd79c5c5 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -246,8 +246,15 @@ static void tcp_ecn_queue_cwr(struct tcp_sock *tp)
static void tcp_ecn_accept_cwr(struct tcp_sock *tp, const struct sk_buff *skb)
{
- if (tcp_hdr(skb)->cwr)
+ if (tcp_hdr(skb)->cwr) {
tp->ecn_flags &= ~TCP_ECN_DEMAND_CWR;
+
+ /* If the sender is telling us it has entered CWR, then its
+ * cwnd may be very low (even just 1 packet), so we should ACK
+ * immediately.
+ */
+ tcp_enter_quickack_mode((struct sock *)tp, 2);
+ }
}
static void tcp_ecn_withdraw_cwr(struct tcp_sock *tp)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Stephen Hemminger @ 2018-07-24 0:53 UTC (permalink / raw)
To: Caleb Raitto; +Cc: mst, jasowang, davem, netdev, Caleb Raitto
In-Reply-To: <20180723231119.142904-1-caleb.raitto@gmail.com>
On Mon, 23 Jul 2018 16:11:19 -0700
Caleb Raitto <caleb.raitto@gmail.com> wrote:
> From: Caleb Raitto <caraitto@google.com>
>
> The driver disables tx napi if it's not certain that completions will
> be processed affine with tx service.
>
> Its heuristic doesn't account for some scenarios where it is, such as
> when the queue pair count matches the core but not hyperthread count.
>
> Allow userspace to override the heuristic. This is an alternative
> solution to that in the linked patch. That added more logic in the
> kernel for these cases, but the agreement was that this was better left
> to user control.
>
> Do not expand the existing napi_tx variable to a ternary value,
> because doing so can break user applications that expect
> boolean ('Y'/'N') instead of integer output. Add a new param instead.
>
> Link: https://patchwork.ozlabs.org/patch/725249/
> Acked-by: Willem de Bruijn <willemb@google.com>
> Acked-by: Jon Olson <jonolson@google.com>
> Signed-off-by: Caleb Raitto <caraitto@google.com>
> ---
Not a fan of this.
Module parameters are frowned on by the distributions because they
never get well tested and they force the user to do magic things
to enable features. It looks like you are using it to paper
over a bug in this case.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit
From: Jakub Kicinski @ 2018-07-24 1:02 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
Jesper Dangaard Brouer
In-Reply-To: <20180722151308.5480-6-toshiaki.makita1@gmail.com>
On Mon, 23 Jul 2018 00:13:05 +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> This allows NIC's XDP to redirect packets to veth. The destination veth
> device enqueues redirected packets to the napi ring of its peer, then
> they are processed by XDP on its peer veth device.
> This can be thought as calling another XDP program by XDP program using
> REDIRECT, when the peer enables driver XDP.
>
> Note that when the peer veth device does not set driver xdp, redirected
> packets will be dropped because the peer is not ready for NAPI.
Often we can't redirect to devices which don't have am xdp program
installed. In your case we can't redirect unless the peer of the
target doesn't have a program installed? :(
Perhaps it is time to reconsider what Saeed once asked for, a flag or
attribute to enable being the destination of a XDP_REDIRECT.
> v2:
> - Drop the part converting xdp_frame into skb when XDP is not enabled.
> - Implement bulk interface of ndo_xdp_xmit.
> - Implement XDP_XMIT_FLUSH bit and drop ndo_xdp_flush.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> ---
> drivers/net/veth.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 4be75c58bc6a..57187e955fea 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -17,6 +17,7 @@
> #include <net/rtnetlink.h>
> #include <net/dst.h>
> #include <net/xfrm.h>
> +#include <net/xdp.h>
> #include <linux/veth.h>
> #include <linux/module.h>
> #include <linux/bpf.h>
> @@ -125,6 +126,11 @@ static void *veth_ptr_to_xdp(void *ptr)
> return (void *)((unsigned long)ptr & ~VETH_XDP_FLAG);
> }
>
> +static void *veth_xdp_to_ptr(void *ptr)
> +{
> + return (void *)((unsigned long)ptr | VETH_XDP_FLAG);
> +}
> +
> static void veth_ptr_free(void *ptr)
> {
> if (veth_is_xdp_frame(ptr))
> @@ -267,6 +273,44 @@ static struct sk_buff *veth_build_skb(void *head, int headroom, int len,
> return skb;
> }
>
> +static int veth_xdp_xmit(struct net_device *dev, int n,
> + struct xdp_frame **frames, u32 flags)
> +{
> + struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
> + struct net_device *rcv;
> + int i, drops = 0;
> +
> + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
> + return -EINVAL;
> +
> + rcv = rcu_dereference(priv->peer);
> + if (unlikely(!rcv))
> + return -ENXIO;
> +
> + rcv_priv = netdev_priv(rcv);
> + /* xdp_ring is initialized on receive side? */
> + if (!rcu_access_pointer(rcv_priv->xdp_prog))
> + return -ENXIO;
> +
> + spin_lock(&rcv_priv->xdp_ring.producer_lock);
> + for (i = 0; i < n; i++) {
> + struct xdp_frame *frame = frames[i];
> + void *ptr = veth_xdp_to_ptr(frame);
> +
> + if (unlikely(xdp_ok_fwd_dev(rcv, frame->len) ||
> + __ptr_ring_produce(&rcv_priv->xdp_ring, ptr))) {
Would you mind sparing a few more words how this is safe vs the
.ndo_close() on the peer? Personally I'm a bit uncomfortable with the
IFF_UP check in xdp_ok_fwd_dev(), I'm not sure what's supposed to
guarantee the device doesn't go down right after that check, or is
already down, but netdev->flags are not atomic...
> + xdp_return_frame_rx_napi(frame);
> + drops++;
> + }
> + }
> + spin_unlock(&rcv_priv->xdp_ring.producer_lock);
> +
> + if (flags & XDP_XMIT_FLUSH)
> + __veth_xdp_flush(rcv_priv);
> +
> + return n - drops;
> +}
> +
> static struct sk_buff *veth_xdp_rcv_one(struct veth_priv *priv,
> struct xdp_frame *frame)
> {
> @@ -760,6 +804,7 @@ static const struct net_device_ops veth_netdev_ops = {
> .ndo_features_check = passthru_features_check,
> .ndo_set_rx_headroom = veth_set_rx_headroom,
> .ndo_bpf = veth_xdp,
> + .ndo_xdp_xmit = veth_xdp_xmit,
> };
>
> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
^ permalink raw reply
* Re: [PATCH v3 bpf-next 6/8] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info
From: Jakub Kicinski @ 2018-07-24 1:22 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
Jesper Dangaard Brouer
In-Reply-To: <20180722151308.5480-7-toshiaki.makita1@gmail.com>
On Mon, 23 Jul 2018 00:13:06 +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> We need some mechanism to disable napi_direct on calling
> xdp_return_frame_rx_napi() from some context.
> When veth gets support of XDP_REDIRECT, it will redirects packets which
> are redirected from other devices. On redirection veth will reuse
> xdp_mem_info of the redirection source device to make return_frame work.
> But in this case .ndo_xdp_xmit() called from veth redirection uses
> xdp_mem_info which is not guarded by NAPI, because the .ndo_xdp_xmit is
> not called directly from the rxq which owns the xdp_mem_info.
>
> This approach introduces a flag in xdp_mem_info to indicate that
> napi_direct should be disabled even when _rx_napi variant is used.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
To be clear - you will modify flags of the original source device if it
ever redirected a frame to a software device like veth? Seems a bit
heavy handed. The xdp_return_frame_rx_napi() is only really used on
error paths, but still.. Also as you note the original NAPI can run
concurrently with your veth dest one, but also with NAPIs of other veth
devices, so the non-atomic xdp.rxq->mem.flags |= XDP_MEM_RF_NO_DIRECT;
makes me worried.
Would you mind elaborating why not handle the RX completely in the NAPI
context of the original device?
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index fcb033f51d8c..1d1bc6553ff2 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -41,6 +41,9 @@ enum xdp_mem_type {
> MEM_TYPE_MAX,
> };
>
> +/* XDP flags for xdp_mem_info */
> +#define XDP_MEM_RF_NO_DIRECT BIT(0) /* don't use napi_direct */
> +
> /* XDP flags for ndo_xdp_xmit */
> #define XDP_XMIT_FLUSH (1U << 0) /* doorbell signal consumer */
> #define XDP_XMIT_FLAGS_MASK XDP_XMIT_FLUSH
> @@ -48,6 +51,7 @@ enum xdp_mem_type {
> struct xdp_mem_info {
> u32 type; /* enum xdp_mem_type, but known size type */
> u32 id;
> + u32 flags;
> };
>
> struct page_pool;
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 57285383ed00..1426c608fd75 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -330,10 +330,12 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
> xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
> page = virt_to_head_page(data);
> - if (xa)
> + if (xa) {
> + napi_direct &= !(mem->flags & XDP_MEM_RF_NO_DIRECT);
> page_pool_put_page(xa->page_pool, page, napi_direct);
> - else
> + } else {
> put_page(page);
> + }
> rcu_read_unlock();
> break;
> case MEM_TYPE_PAGE_SHARED:
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Willem de Bruijn @ 2018-07-24 1:23 UTC (permalink / raw)
To: Stephen Hemminger
Cc: caleb.raitto, Michael S. Tsirkin, Jason Wang, David Miller,
Network Development, caraitto
In-Reply-To: <20180723175326.583ce2b8@xeon-e3>
On Mon, Jul 23, 2018 at 8:55 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Mon, 23 Jul 2018 16:11:19 -0700
> Caleb Raitto <caleb.raitto@gmail.com> wrote:
>
> > From: Caleb Raitto <caraitto@google.com>
> >
> > The driver disables tx napi if it's not certain that completions will
> > be processed affine with tx service.
> >
> > Its heuristic doesn't account for some scenarios where it is, such as
> > when the queue pair count matches the core but not hyperthread count.
> >
> > Allow userspace to override the heuristic. This is an alternative
> > solution to that in the linked patch. That added more logic in the
> > kernel for these cases, but the agreement was that this was better left
> > to user control.
> >
> > Do not expand the existing napi_tx variable to a ternary value,
> > because doing so can break user applications that expect
> > boolean ('Y'/'N') instead of integer output. Add a new param instead.
> >
> > Link: https://patchwork.ozlabs.org/patch/725249/
> > Acked-by: Willem de Bruijn <willemb@google.com>
> > Acked-by: Jon Olson <jonolson@google.com>
> > Signed-off-by: Caleb Raitto <caraitto@google.com>
> > ---
>
> Not a fan of this.
> Module parameters are frowned on by the distributions because they
> never get well tested and they force the user to do magic things
> to enable features. It looks like you are using it to paper
> over a bug in this case.
This has actually been a catch-22 that this patch tries to break.
In micro benchmarks napi-tx was an improvement for most cases. We need
wider validation to make it default. Or even to start enabling it for some
users. But we cannot get the data, because understandably no one is
going to make it default without more data.
Enabling the feature selectively to safely roll out is the intent of
(temporary) param napi_tx. But the requirement to have
has_affinity_set is proving a real obstruction.
Especially in cases where we enable the feature to do A:B comparisons,
and thus are monitoring performance metrics closely, we should be able
to override the kernel heuristic.
^ permalink raw reply
* Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge
From: D'Souza, Nelson @ 2018-07-24 1:43 UTC (permalink / raw)
To: David Ahern, netdev@vger.kernel.org
In-Reply-To: <51e237af-2db6-8905-22c9-9739f7d5a9b0@cumulusnetworks.com>
Hi David,
I copy and pasted the configs onto my device, but pings on test-vrf do not work in my setup.
I'm essentially seeing the same issue as I reported before.
In this case, pings sent out on test-vrf (host ns) are received and replied to by the loopback interface (foo ns). Although the replies are seen at the test-vrf level, they are not locally delivered to the ping application.
Logs are as follows...
a) pings on test-vrf or br0 fail.
# ping -I test-vrf 172.16.2.2 -c1 -w1
PING 172.16.2.2 (172.16.2.2): 56 data bytes
--- 172.16.2.2 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
b) tcpdump in the foo namespace, shows icmp echos/replies on veth2
# ip netns exec foo tcpdump -i veth2 icmp -c 2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:34:13.205210 IP 172.16.1.1 > 172.16.2.2: ICMP echo request, id 19513, seq 0, length 64
18:34:13.205253 IP 172.16.2.2 > 172.16.1.1: ICMP echo reply, id 19513, seq 0, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel
c) tcpdump in the host namespace, shows icmp echos/replies on test-vrf, br0 and veth1:
# tcpdump -i test-vrf icmp -c 2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on test-vrf, link-type EN10MB (Ethernet), capture size 262144 bytes
18:34:13.204061 IP 172.16.1.1 > 172.16.2.2: ICMP echo request, id 19513, seq 0, length 64
18:34:13.205278 IP 172.16.2.2 > 172.16.1.1: ICMP echo reply, id 19513, seq 0, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel
Thanks,
Nelson
On 7/23/18, 3:00 PM, "David Ahern" <dsa@cumulusnetworks.com> wrote:
On 7/20/18 1:03 PM, D'Souza, Nelson wrote:
> Setup is as follows:
>
> ethUSB(ingress port) -> mgmtbr0 (bridge) -> mgmtvrf (vrf)
| netns foo
[ test-vrf ] |
| |
[ br0 ] 172.16.1.1 |
| |
[ veth1 ] ============|======= [ veth2 ] lo
| 172.16.1.2 172.16.2.2
|
Copy and paste the following into your environment:
ip netns add foo
ip li add veth1 type veth peer name veth2
ip li set veth2 netns foo
ip -netns foo li set lo up
ip -netns foo li set veth2 up
ip -netns foo addr add 172.16.1.2/24 dev veth2
ip li add test-vrf type vrf table 123
ip li set test-vrf up
ip ro add vrf test-vrf unreachable default
ip li add br0 type bridge
ip li set veth1 master br0
ip li set veth1 up
ip li set br0 up
ip addr add dev br0 172.16.1.1/24
ip li set br0 master test-vrf
ip -netns foo addr add 172.16.2.2/32 dev lo
ip ro add vrf test-vrf 172.16.2.2/32 via 172.16.1.2
Does ping work?
# ping -I test-vrf 172.16.2.2
ping: Warning: source address might be selected on device other than
test-vrf.
PING 172.16.2.2 (172.16.2.2) from 172.16.1.1 test-vrf: 56(84) bytes of data.
64 bytes from 172.16.2.2: icmp_seq=1 ttl=64 time=0.228 ms
64 bytes from 172.16.2.2: icmp_seq=2 ttl=64 time=0.263 ms
and:
# ping -I br0 172.16.2.2
PING 172.16.2.2 (172.16.2.2) from 172.16.1.1 br0: 56(84) bytes of data.
64 bytes from 172.16.2.2: icmp_seq=1 ttl=64 time=0.227 ms
64 bytes from 172.16.2.2: icmp_seq=2 ttl=64 time=0.223 ms
^C
--- 172.16.2.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.223/0.225/0.227/0.002 ms
^ permalink raw reply
* Re: [PATCH v3 bpf-next 2/8] veth: Add driver XDP
From: Toshiaki Makita @ 2018-07-24 1:47 UTC (permalink / raw)
To: Jakub Kicinski, Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <20180723172324.248c4dc9@cakuba.netronome.com>
Hi Jakub,
Thanks for reviewing!
On 2018/07/24 9:23, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 00:13:02 +0900, Toshiaki Makita wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> This is the basic implementation of veth driver XDP.
>>
>> Incoming packets are sent from the peer veth device in the form of skb,
>> so this is generally doing the same thing as generic XDP.
>>
>> This itself is not so useful, but a starting point to implement other
>> useful veth XDP features like TX and REDIRECT.
>>
>> This introduces NAPI when XDP is enabled, because XDP is now heavily
>> relies on NAPI context. Use ptr_ring to emulate NIC ring. Tx function
>> enqueues packets to the ring and peer NAPI handler drains the ring.
>>
>> Currently only one ring is allocated for each veth device, so it does
>> not scale on multiqueue env. This can be resolved by allocating rings
>> on the per-queue basis later.
>>
>> Note that NAPI is not used but netif_rx is used when XDP is not loaded,
>> so this does not change the default behaviour.
>>
>> v3:
>> - Fix race on closing the device.
>> - Add extack messages in ndo_bpf.
>>
>> v2:
>> - Squashed with the patch adding NAPI.
>> - Implement adjust_tail.
>> - Don't acquire consumer lock because it is guarded by NAPI.
>> - Make poll_controller noop since it is unnecessary.
>> - Register rxq_info on enabling XDP rather than on opening the device.
>>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
>> +static struct sk_buff *veth_xdp_rcv_skb(struct veth_priv *priv,
>> + struct sk_buff *skb)
>> +{
>> + u32 pktlen, headroom, act, metalen;
>> + void *orig_data, *orig_data_end;
>> + int size, mac_len, delta, off;
>> + struct bpf_prog *xdp_prog;
>> + struct xdp_buff xdp;
>> +
>> + rcu_read_lock();
>> + xdp_prog = rcu_dereference(priv->xdp_prog);
>> + if (unlikely(!xdp_prog)) {
>> + rcu_read_unlock();
>> + goto out;
>> + }
>> +
>> + mac_len = skb->data - skb_mac_header(skb);
>> + pktlen = skb->len + mac_len;
>> + size = SKB_DATA_ALIGN(VETH_XDP_HEADROOM + pktlen) +
>> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>> + if (size > PAGE_SIZE)
>> + goto drop;
>> +
>> + headroom = skb_headroom(skb) - mac_len;
>> + if (skb_shared(skb) || skb_head_is_locked(skb) ||
>> + skb_is_nonlinear(skb) || headroom < XDP_PACKET_HEADROOM) {
>> + struct sk_buff *nskb;
>> + void *head, *start;
>> + struct page *page;
>> + int head_off;
>> +
>> + page = alloc_page(GFP_ATOMIC);
>> + if (!page)
>> + goto drop;
>> +
>> + head = page_address(page);
>> + start = head + VETH_XDP_HEADROOM;
>> + if (skb_copy_bits(skb, -mac_len, start, pktlen)) {
>> + page_frag_free(head);
>> + goto drop;
>> + }
>> +
>> + nskb = veth_build_skb(head,
>> + VETH_XDP_HEADROOM + mac_len, skb->len,
>> + PAGE_SIZE);
>> + if (!nskb) {
>> + page_frag_free(head);
>> + goto drop;
>> + }
>
>> +static int veth_enable_xdp(struct net_device *dev)
>> +{
>> + struct veth_priv *priv = netdev_priv(dev);
>> + int err;
>> +
>> + if (!xdp_rxq_info_is_reg(&priv->xdp_rxq)) {
>> + err = xdp_rxq_info_reg(&priv->xdp_rxq, dev, 0);
>> + if (err < 0)
>> + return err;
>> +
>> + err = xdp_rxq_info_reg_mem_model(&priv->xdp_rxq,
>> + MEM_TYPE_PAGE_SHARED, NULL);
>
> nit: doesn't matter much but looks like a mix of MEM_TYPE_PAGE_SHARED
> and MEM_TYPE_PAGE_ORDER0
Actually I'm not sure when to use MEM_TYPE_PAGE_ORDER0. It seems a page
allocated by alloc_page() can be freed by page_frag_free() and it is
more lightweight than put_page(), isn't it?
virtio_net is doing it in a similar way.
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
From: Toshiaki Makita @ 2018-07-24 2:53 UTC (permalink / raw)
To: Tonghao Zhang
Cc: Linux Kernel Network Developers, toshiaki.makita1, virtualization,
mst
In-Reply-To: <CAMDZJNXWs+yqAcZ-7gW6RQjen0-mzfJ-Ar-O0_wttse2A-3-HQ@mail.gmail.com>
On 2018/07/24 2:31, Tonghao Zhang wrote:
> On Mon, Jul 23, 2018 at 10:20 PM Toshiaki Makita
> <toshiaki.makita1@gmail.com> wrote:
>>
>> On 18/07/23 (月) 21:43, Tonghao Zhang wrote:
>>> On Mon, Jul 23, 2018 at 5:58 PM Toshiaki Makita
>>> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>>>
>>>> On 2018/07/22 3:04, xiangxia.m.yue@gmail.com wrote:
>>>>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>>>
>>>>> Factor out generic busy polling logic and will be
>>>>> used for in tx path in the next patch. And with the patch,
>>>>> qemu can set differently the busyloop_timeout for rx queue.
>>>>>
>>>>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>>>> ---
>>>> ...
>>>>> +static void vhost_net_busy_poll_vq_check(struct vhost_net *net,
>>>>> + struct vhost_virtqueue *rvq,
>>>>> + struct vhost_virtqueue *tvq,
>>>>> + bool rx)
>>>>> +{
>>>>> + struct socket *sock = rvq->private_data;
>>>>> +
>>>>> + if (rx) {
>>>>> + if (!vhost_vq_avail_empty(&net->dev, tvq)) {
>>>>> + vhost_poll_queue(&tvq->poll);
>>>>> + } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
>>>>> + vhost_disable_notify(&net->dev, tvq);
>>>>> + vhost_poll_queue(&tvq->poll);
>>>>> + }
>>>>> + } else if ((sock && sk_has_rx_data(sock->sk)) &&
>>>>> + !vhost_vq_avail_empty(&net->dev, rvq)) {
>>>>> + vhost_poll_queue(&rvq->poll);
>>>>
>>>> Now we wait for vq_avail for rx as well, I think you cannot skip
>>>> vhost_enable_notify() on tx. Probably you might want to do:
>>> I think vhost_enable_notify is needed.
>>>
>>>> } else if (sock && sk_has_rx_data(sock->sk)) {
>>>> if (!vhost_vq_avail_empty(&net->dev, rvq)) {
>>>> vhost_poll_queue(&rvq->poll);
>>>> } else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
>>>> vhost_disable_notify(&net->dev, rvq);
>>>> vhost_poll_queue(&rvq->poll);
>>>> }
>>>> }
>>> As Jason review as before, we only want rx kick when packet is pending at
>>> socket but we're out of available buffers. So we just enable notify,
>>> but not poll it ?
>>>
>>> } else if ((sock && sk_has_rx_data(sock->sk)) &&
>>> !vhost_vq_avail_empty(&net->dev, rvq)) {
>>> vhost_poll_queue(&rvq->poll);
>>> else {
>>> vhost_enable_notify(&net->dev, rvq);
>>> }
>>
>> When vhost_enable_notify() returns true the avail becomes non-empty
>> while we are enabling notify. We may delay the rx process if we don't
>> check the return value of vhost_enable_notify().
> I got it thanks.
>>>> Also it's better to care vhost_net_disable_vq()/vhost_net_enable_vq() on tx?
>>> I cant find why it is better, if necessary, we can do it.
>>
>> The reason is pretty simple... we are busypolling the socket so we don't
>> need rx wakeups during it?
> OK, but one question, how about rx? do we use the
> vhost_net_disable_vq/vhost_net_ensable_vq on rx ?
If we are busypolling the sock tx buf? I'm not sure if polling it
improves the performance.
--
Toshiaki Makita
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH bpf-next] bpf: btf: fix inconsistent IS_ERR and PTR_ERR
From: YueHaibing @ 2018-07-24 2:55 UTC (permalink / raw)
To: ast, daniel, quentin.monnet, jakub.kicinski, bhole_prashant_q7,
osk
Cc: linux-kernel, netdev, davem, YueHaibing
Fix inconsistent IS_ERR and PTR_ERR in get_btf,
the proper pointer to be passed as argument is '*btf'
This issue was detected with the help of Coccinelle.
Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
tools/bpf/bpftool/map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 9c81918..0ee3ba4 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -230,7 +230,7 @@ static int get_btf(struct bpf_map_info *map_info, struct btf **btf)
*btf = btf__new((__u8 *)btf_info.btf, btf_info.btf_size, NULL);
if (IS_ERR(*btf)) {
- err = PTR_ERR(btf);
+ err = PTR_ERR(*btf);
*btf = NULL;
}
--
2.7.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox