search for: tuntap

On Thu, Sep 06, 2018 at 12:05:24PM +0800, Jason Wang wrote: > This patch implement TUN_MSG_PTR msg_control type. This type allows > the caller to pass an array of XDP buffs to tuntap through ptr field > of the tun_msg_control. If an XDP program is attached, tuntap can run > XDP program directly. If not, tuntap will build skb and do a fast > receiving since part of the work has been done by vhost_net. > > This will avoid lots of indirect calls thus improves the i...

This patch implement TUN_MSG_PTR msg_control type. This type allows the caller to pass an array of XDP buffs to tuntap through ptr field of the tun_msg_control. If an XDP program is attached, tuntap can run XDP program directly. If not, tuntap will build skb and do a fast receiving since part of the work has been done by vhost_net. This will avoid lots of indirect calls thus improves the icache utilization and all...

This patch move the bh enabling a little bit earlier, this will be used for factoring out the core XDP logic of tuntap. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/tun.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index d3677a544b56..372caf7d67d9 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1726,22...

...do? Keep trying until it succeeds? > > I think it's better to just use NAPI_POLL_WEIGHT instead and DTRT here. > > > > Well, looking at how set_coalesce is implemented in other drivers, -EINVAL > is usually used when user give a value that exceeds the limitation. For > tuntap, what missed here is probably just a documentation for coalescing in > tuntap.txt. (Or extend ethtool to return the max value). This seems much > better than silently reduce the value to the limitation. > > Thanks I don't think it's better, it's mostly that 1. there's...

...do? Keep trying until it succeeds? > > I think it's better to just use NAPI_POLL_WEIGHT instead and DTRT here. > > > > Well, looking at how set_coalesce is implemented in other drivers, -EINVAL > is usually used when user give a value that exceeds the limitation. For > tuntap, what missed here is probably just a documentation for coalescing in > tuntap.txt. (Or extend ethtool to return the max value). This seems much > better than silently reduce the value to the limitation. > > Thanks I don't think it's better, it's mostly that 1. there's...

...ecently I added two more Ubuntu 18.04 servers at the same location and attempted to link them to the Tinc mesh already established. The 18.04 servers do not allow me to use the net-tools ipconfig command and so I have adapted my tinc-up commands to use iproute2 commands. #!/bin/sh # tinc-up ip tuntap add dev $INTERFACE mode tun ip addr add 10.0.0.3/24 dev $INTERFACE ip link set dev $INTERFACE up However, when I run this command I get the error Error: either "name" is duplicate, or "tun" is a garbage. Command line is not complete. Try option "help" Cannot find...

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/tun.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 44d4f3d..24ecd82 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1697,6 +1697,8 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun, goto err_xdp; } } + rcu_read_unlock();

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/tun.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 2c548bd20393..d3677a544b56 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -113,7 +113,6 @@ do { \ } while (0) #endif -#define TUN_HEADROOM 256 #define TUN_RX_PAD (NET_IP_ALIGN +

There's no need to duplicate page get logic in each action. So this patch tries to get page and calculate the offset before processing XDP actions, and undo them when meet errors (we don't care the performance on errors). This will be used for factoring out XDP logic. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/tun.c | 37 ++++++++++++++++---------------------

If we're sure not to go native XDP, there's no need for several things like bh and rcu stuffs. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/tun.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index f8cdcfa392c3..389aa0727cc6 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1675,10

This will allow adding batch flushing on top. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/tun.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 21b125020b3b..ff1cbf3ebd50 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1646,7 +1646,6 @@ static u32 tun_do_xdp(struct tun_struct *tun, switch

On Thu, Sep 06, 2018 at 12:05:17PM +0800, Jason Wang wrote: > Signed-off-by: Jason Wang <jasowang at redhat.com> Acked-by: Michael S. Tsirkin <mst at redhat.com> any idea why didn't we do this straight away? > --- > drivers/net/tun.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index

On Thu, Sep 06, 2018 at 12:05:20PM +0800, Jason Wang wrote: > If we're sure not to go native XDP, there's no need for several things > like bh and rcu stuffs. > > Signed-off-by: Jason Wang <jasowang at redhat.com> True... > --- > drivers/net/tun.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/tun.c

On Thu, Sep 06, 2018 at 12:05:22PM +0800, Jason Wang wrote: > This will allow adding batch flushing on top. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/net/tun.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index 21b125020b3b..ff1cbf3ebd50 100644 > ---

On Fri, Sep 07, 2018 at 11:29:34AM +0800, Jason Wang wrote: > > > + if (act != XDP_PASS) > > > + goto out; > > likely? > > It depends on the XDP program, so I tend not to use it. Point is XDP_PASS is already slow. -- MST

On Fri, Sep 07, 2018 at 11:22:00AM +0800, Jason Wang wrote: > > > @@ -1668,6 +1668,9 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun, > > > if (copied != len) > > > return ERR_PTR(-EFAULT); > > > + get_page(alloc_frag->page); > > > + alloc_frag->offset += buflen; > > > + > > This adds an atomic op on XDP_DROP

Thanks to the batched XDP buffs through msg_control. Instead of calling put_page() for each page which involves a atomic operation, let's batch them by record the last page that needs to be freed and its refcnt count and free them in a batch. Testpmd(virtio-user + vhost_net) + XDP_DROP shows 3.8% improvement. Before: 4.71Mpps After : 4.89Mpps Signed-off-by: Jason Wang <jasowang at

This patch split out XDP logic into a single function. This make it to be reused by XDP batching path in the following patch. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/tun.c | 84 ++++++++++++++++++++++++++++------------------- 1 file changed, 51 insertions(+), 33 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 389aa0727cc6..21b125020b3b

On 2018?09?07? 01:14, Michael S. Tsirkin wrote: > On Thu, Sep 06, 2018 at 12:05:19PM +0800, Jason Wang wrote: >> There's no need to duplicate page get logic in each action. So this >> patch tries to get page and calculate the offset before processing XDP >> actions, and undo them when meet errors (we don't care the performance >> on errors). This will be used for

On 2018?09?07? 01:21, Michael S. Tsirkin wrote: > On Thu, Sep 06, 2018 at 12:05:21PM +0800, Jason Wang wrote: >> This patch split out XDP logic into a single function. This make it to >> be reused by XDP batching path in the following patch. >> >> Signed-off-by: Jason Wang <jasowang at redhat.com> >> --- >> drivers/net/tun.c | 84