All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: daniel@iogearbox.net, shm@cumulusnetworks.com,
	davem@davemloft.net, tgraf@suug.ch, alexei.starovoitov@gmail.com,
	john.r.fastabend@intel.com, netdev@vger.kernel.org,
	brouer@redhat.com
Subject: Re: [net-next PATCH v5 4/6] virtio_net: add dedicated XDP transmit queues
Date: Thu, 8 Dec 2016 09:10:28 -0800	[thread overview]
Message-ID: <58499404.3040702@gmail.com> (raw)
In-Reply-To: <20161208075459-mutt-send-email-mst@kernel.org>

On 16-12-07 09:59 PM, Michael S. Tsirkin wrote:
> On Wed, Dec 07, 2016 at 12:12:23PM -0800, John Fastabend wrote:
>> XDP requires using isolated transmit queues to avoid interference
>> with normal networking stack (BQL, NETDEV_TX_BUSY, etc).
>> This patch
>> adds a XDP queue per cpu when a XDP program is loaded and does not
>> expose the queues to the OS via the normal API call to
>> netif_set_real_num_tx_queues(). This way the stack will never push
>> an skb to these queues.
>>
>> However virtio/vhost/qemu implementation only allows for creating
>> TX/RX queue pairs at this time so creating only TX queues was not
>> possible. And because the associated RX queues are being created I
>> went ahead and exposed these to the stack and let the backend use
>> them. This creates more RX queues visible to the network stack than
>> TX queues which is worth mentioning but does not cause any issues as
>> far as I can tell.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>>  drivers/net/virtio_net.c |   30 ++++++++++++++++++++++++++++--
>>  1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index a009299..28b1196 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -114,6 +114,9 @@ struct virtnet_info {
>>  	/* # of queue pairs currently used by the driver */
>>  	u16 curr_queue_pairs;
>>  
>> +	/* # of XDP queue pairs currently used by the driver */
>> +	u16 xdp_queue_pairs;
>> +
>>  	/* I like... big packets and I cannot lie! */
>>  	bool big_packets;
>>  
>> @@ -1547,7 +1550,8 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
>>  	unsigned long int max_sz = PAGE_SIZE - sizeof(struct padded_vnet_hdr);
>>  	struct virtnet_info *vi = netdev_priv(dev);
>>  	struct bpf_prog *old_prog;
>> -	int i;
>> +	u16 xdp_qp = 0, curr_qp;
>> +	int i, err;
>>  
>>  	if ((dev->features & NETIF_F_LRO) && prog) {
>>  		netdev_warn(dev, "can't set XDP while LRO is on, disable LRO first\n");
>> @@ -1564,12 +1568,34 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
>>  		return -EINVAL;
>>  	}
>>  
>> +	curr_qp = vi->curr_queue_pairs - vi->xdp_queue_pairs;
>> +	if (prog)
>> +		xdp_qp = nr_cpu_ids;
>> +
>> +	/* XDP requires extra queues for XDP_TX */
>> +	if (curr_qp + xdp_qp > vi->max_queue_pairs) {
>> +		netdev_warn(dev, "request %i queues but max is %i\n",
>> +			    curr_qp + xdp_qp, vi->max_queue_pairs);
>> +		return -ENOMEM;
>> +	}
> 
> Can't we disable XDP_TX somehow? Many people might only want RX drop,
> and extra queues are not always there.
> 

Alexei, Daniel, any thoughts on this?

I know we were trying to claim some base level of feature support for
all XDP drivers. I am sympathetic to this argument though for DDOS we
do not need XDP_TX support. And virtio can become queue constrained
in some cases.

But, I do not want to silently degrade to RX mode and trying to check
this through the verifier appears challenging. And I'm not thrilled
about more knobs :/ Maybe an escape to force RX mode in sysfs or at
program load time would be OK?

I think this is an improvement that can go on my list along with LRO.

.John

  reply	other threads:[~2016-12-08 17:10 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-07 20:10 [net-next PATCH v5 0/6] XDP for virtio_net John Fastabend
2016-12-07 20:11 ` [net-next PATCH v5 1/6] net: virtio dynamically disable/enable LRO John Fastabend
2016-12-08 21:36   ` Michael S. Tsirkin
2016-12-09  0:04     ` John Fastabend
2016-12-09  3:05       ` Michael S. Tsirkin
2016-12-14 13:31       ` Michael S. Tsirkin
2016-12-14 17:01         ` John Fastabend
2016-12-15 16:35           ` Michael S. Tsirkin
2016-12-07 20:11 ` [net-next PATCH v5 2/6] net: xdp: add invalid buffer warning John Fastabend
2016-12-07 20:11 ` [net-next PATCH v5 3/6] virtio_net: Add XDP support John Fastabend
2016-12-08  4:48   ` Michael S. Tsirkin
2016-12-08  5:14     ` John Fastabend
2016-12-08  5:54       ` Michael S. Tsirkin
2016-12-07 20:12 ` [net-next PATCH v5 4/6] virtio_net: add dedicated XDP transmit queues John Fastabend
2016-12-08  5:59   ` Michael S. Tsirkin
2016-12-08 17:10     ` John Fastabend [this message]
2016-12-07 20:12 ` [net-next PATCH v5 5/6] virtio_net: add XDP_TX support John Fastabend
2016-12-08  6:11   ` Michael S. Tsirkin
2016-12-08 18:18     ` John Fastabend
2016-12-08 21:08       ` Michael S. Tsirkin
2016-12-08 21:18       ` Michael S. Tsirkin
2016-12-08 21:25         ` John Fastabend
2016-12-08 21:45           ` Michael S. Tsirkin
2016-12-08 21:51             ` John Fastabend
2016-12-07 20:13 ` [net-next PATCH v5 6/6] virtio_net: xdp, add slowpath case for non contiguous buffers John Fastabend
2016-12-08 19:17 ` [net-next PATCH v5 0/6] XDP for virtio_net David Miller
2016-12-08 19:38   ` Alexei Starovoitov
2016-12-08 20:46     ` John Fastabend
2016-12-08 20:58       ` Michael S. Tsirkin
2016-12-08 21:10         ` Michael S. Tsirkin
2016-12-08 21:08       ` Alexei Starovoitov
2016-12-08 22:16       ` David Miller
2016-12-09  3:01         ` Michael S. Tsirkin
2016-12-13  8:46     ` XDP_DROP and XDP_TX (Was: Re: [net-next PATCH v5 0/6] XDP for virtio_net) Jesper Dangaard Brouer
2016-12-08 21:16   ` [net-next PATCH v5 0/6] XDP for virtio_net Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58499404.3040702@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=john.r.fastabend@intel.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=shm@cumulusnetworks.com \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.