Re: [PATCH net-next 3/3] virtio-net: clean tx descriptors from rx napi

On Fri, Apr 7, 2017 at 3:28 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Apr 03, 2017 at 01:02:13AM -0400, Willem de Bruijn wrote: >> On Sun, Apr 2, 2017 at 10:47 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Sun, Apr 02, 2017 at 04:10:12PM

Re: [PATCH net-next 3/3] virtio-net: clean tx descriptors from rx napi

On Sun, Apr 2, 2017 at 10:47 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Sun, Apr 02, 2017 at 04:10:12PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <will...@google.com> >> >> Amortize the cost of virtual interrupts by doing both rx and tx

Re: [PATCH net-next 2/3] virtio-net: transmit napi

On Sun, Apr 2, 2017 at 10:30 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Sun, Apr 02, 2017 at 04:10:11PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <will...@google.com> >> >> Convert virtio-net to a standard napi tx completion path. This e

[PATCH net-next 3/3] virtio-net: clean tx descriptors from rx napi

From: Willem de Bruijn <will...@google.com> Amortize the cost of virtual interrupts by doing both rx and tx work on reception of a receive interrupt if tx napi is enabled. With VIRTIO_F_EVENT_IDX, this suppresses most explicit tx completion interrupts for bidirectional workloads. Sign

Re: [PATCH net-next 3/3] virtio-net: clean tx descriptors from rx napi

On Fri, Apr 7, 2017 at 5:10 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Fri, Apr 07, 2017 at 04:59:58PM -0400, Willem de Bruijn wrote: >> On Fri, Apr 7, 2017 at 3:28 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Mon, Apr 03, 2017 at 01:02:13AM

[PATCH net-next 1/3] virtio-net: napi helper functions

From: Willem de Bruijn <will...@google.com> Prepare virtio-net for tx napi by converting existing napi code to use helper functions. This also deduplicates some logic. Signed-off-by: Willem de Bruijn <will...@google.com> Signed-off-by: Jason Wang <jasow...@redhat.com>

[PATCH net-next 2/3] virtio-net: transmit napi

From: Willem de Bruijn <will...@google.com> Convert virtio-net to a standard napi tx completion path. This enables better TCP pacing using TCP small queues and increases single stream throughput. The virtio-net driver currently cleans tx descriptors on transmission of new p

[PATCH net-next 0/3] virtio-net tx napi

From: Willem de Bruijn <will...@google.com> Add napi for virtio-net transmit completion processing. Based on previous patchsets by Jason Wang: [RFC V7 PATCH 0/7] enable tx interrupts for virtio-net http://lkml.iu.edu/hypermail/linux/kernel/1505.3/00245.html Changes: RFC

Re: [PATCH net-next v2 2/5] virtio-net: transmit napi

On Mon, Apr 24, 2017 at 1:14 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Apr 24, 2017 at 01:05:45PM -0400, Willem de Bruijn wrote: >> On Mon, Apr 24, 2017 at 12:40 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Fri, Apr 21, 2017 at 10:50:12AM

[PATCH net-next v2 1/5] virtio-net: napi helper functions

From: Willem de Bruijn <will...@google.com> Prepare virtio-net for tx napi by converting existing napi code to use helper functions. This also deduplicates some logic. Signed-off-by: Willem de Bruijn <will...@google.com> Signed-off-by: Jason Wang <jasow...@redhat.com>

[PATCH net-next v2 0/5] virtio-net tx napi

From: Willem de Bruijn <will...@google.com> Add napi for virtio-net transmit completion processing. Changes: v1 -> v2: - disable by default - disable unless affinity_hint_set because cache misses add up to a third higher cycle cost, e.g., in TCP

[PATCH net-next v2 2/5] virtio-net: transmit napi

From: Willem de Bruijn <will...@google.com> Convert virtio-net to a standard napi tx completion path. This enables better TCP pacing using TCP small queues and increases single stream throughput. The virtio-net driver currently cleans tx descriptors on transmission of new p

Re: [PATCH net-next v2 5/5] virtio-net: keep tx interrupts disabled unless kick

>> - if (!use_napi) >> + if (use_napi) { >> + if (kick) >> + virtqueue_enable_cb_delayed(sq->vq); >> + else >> + virtqueue_disable_cb(sq->vq); > > > Since virtqueue_disable_cb() do nothing for event idx. I wonder

Re: [PATCH net-next v2 2/5] virtio-net: transmit napi

On Thu, Apr 20, 2017 at 2:27 AM, Jason Wang <jasow...@redhat.com> wrote: > > > On 2017年04月19日 04:21, Willem de Bruijn wrote: >> >> +static void virtnet_napi_tx_enable(struct virtnet_info *vi, >> + struct virtqueue *vq, >> +

[PATCH net-next v2 5/5] virtio-net: keep tx interrupts disabled unless kick

From: Willem de Bruijn <will...@google.com> Tx napi mode increases the rate of transmit interrupts. Suppress some by masking interrupts while more packets are expected. The interrupts will be reenabled before the last packet is sent. This optimization reduces the througput drop with t

[PATCH net-next v2 4/5] virtio-net: clean tx descriptors from rx napi

From: Willem de Bruijn <will...@google.com> Amortize the cost of virtual interrupts by doing both rx and tx work on reception of a receive interrupt if tx napi is enabled. With VIRTIO_F_EVENT_IDX, this suppresses most explicit tx completion interrupts for bidirectional workloads. Sign

Re: [PATCH net-next v2 2/5] virtio-net: transmit napi

>> static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) >> { >> struct virtio_net_hdr_mrg_rxbuf *hdr; >> @@ -1130,9 +1172,11 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, >> struct net_device *dev) >> int err; >> struct netdev_queue *txq =

[PATCH net-next v2 3/5] virtio-net: move free_old_xmit_skbs

From: Willem de Bruijn <will...@google.com> An upcoming patch will call free_old_xmit_skbs indirectly from virtnet_poll. Move the function above this to avoid having to introduce a forward declaration. This is a pure move: no code changes. Signed-off-by: Willem de Bruijn <will...@g

Re: [PATCH net-next v2 2/5] virtio-net: transmit napi

>>> Maybe I was wrong, but according to Michael's comment it looks like he >>> want >>> check affinity_hint_set just for speculative tx polling on rx napi >>> instead >>> of disabling it at all. >>> >>> And I'm not convinced this is really needed, driver only provide affinity >>> hint instead of

Re: [PATCH net-next v2 2/5] virtio-net: transmit napi

On Thu, Apr 20, 2017 at 12:02 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: >>> static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) >>> { >>> struct virtio_net_hdr_mrg_rxbuf *hdr; >>> @@ -1130,9 +1172,11 @@ static

Re: [PATCH net-next v2 5/5] virtio-net: keep tx interrupts disabled unless kick

On Thu, Apr 20, 2017 at 10:03 AM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: >>> - if (!use_napi) >>> + if (use_napi) { >>> + if (kick) >>> + virtqueue_enable_cb

Re: [PATCH net-next v2 2/5] virtio-net: transmit napi

On Mon, Apr 24, 2017 at 12:40 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Fri, Apr 21, 2017 at 10:50:12AM -0400, Willem de Bruijn wrote: >> >>> Maybe I was wrong, but according to Michael's comment it looks like he >> >>> want >> >>> c

[PATCH net-next v3 1/5] virtio-net: napi helper functions

From: Willem de Bruijn <will...@google.com> Prepare virtio-net for tx napi by converting existing napi code to use helper functions. This also deduplicates some logic. Signed-off-by: Willem de Bruijn <will...@google.com> Signed-off-by: Jason Wang <jasow...@redhat.com>

[PATCH net-next v3 2/5] virtio-net: transmit napi

From: Willem de Bruijn <will...@google.com> Convert virtio-net to a standard napi tx completion path. This enables better TCP pacing using TCP small queues and increases single stream throughput. The virtio-net driver currently cleans tx descriptors on transmission of new p

[PATCH net-next v3 3/5] virtio-net: move free_old_xmit_skbs

From: Willem de Bruijn <will...@google.com> An upcoming patch will call free_old_xmit_skbs indirectly from virtnet_poll. Move the function above this to avoid having to introduce a forward declaration. This is a pure move: no code changes. Signed-off-by: Willem de Bruijn <will...@g

[PATCH net-next v3 5/5] virtio-net: keep tx interrupts disabled unless kick

From: Willem de Bruijn <will...@google.com> Tx napi mode increases the rate of transmit interrupts. Suppress some by masking interrupts while more packets are expected. The interrupts will be reenabled before the last packet is sent. This optimization reduces the througput drop with t

[PATCH net-next v3 4/5] virtio-net: clean tx descriptors from rx napi

From: Willem de Bruijn <will...@google.com> Amortize the cost of virtual interrupts by doing both rx and tx work on reception of a receive interrupt if tx napi is enabled. With VIRTIO_F_EVENT_IDX, this suppresses most explicit tx completion interrupts for bidirectional workloads. Sign

[PATCH net-next] virtio-net: on tx, only call napi_disable if tx napi is on

From: Willem de Bruijn <will...@google.com> As of tx napi, device down (`ip link set dev $dev down`) hangs unless tx napi is enabled. Else napi_enable is not called, so napi_disable will spin on test_and_set_bit NAPI_STATE_SCHED. Only call napi_disable if tx napi is enabled. Fixes: 5a719c

Re: [PATCH net-next v3 2/5] virtio-net: transmit napi

On Tue, Apr 25, 2017 at 4:36 AM, Jason Wang <jasow...@redhat.com> wrote: > > > On 2017年04月25日 01:49, Willem de Bruijn wrote: >> >> @@ -1371,8 +1419,10 @@ static int virtnet_close(struct net_device *dev) >> /* Make sure r

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

>> > An issue of the referenced patch is that sndbuf could be smaller than low >> > watermark. > We cannot determine the low watermark properly because of not only sndbuf size > issue but also the fact that the upper vhost-net cannot directly see how much > descriptor is currently available at the

Re: [PATCH net-next] virtio-net: make napi_tx param easier to grasp

On Sat, Aug 19, 2017 at 2:37 AM, Koichiro Den wrote: > The module param napi_tx needs not to be writable for now since we do > not have any means of activating/deactivating it online, A virtio_net device inherits its napi tx mode from the global napi_tx flag on device up. It

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Sat, Aug 19, 2017 at 2:38 AM, Koichiro Den wrote: > Facing the possible unbounded delay relying on freeing on xmit path, > we also better to invoke and clear the upper layer zerocopy callback > beforehand to keep them from waiting for unbounded duration in vain. Good

[PATCH net-next v2] vhost_net: do not stall on zerocopy depletion

From: Willem de Bruijn <will...@google.com> Vhost-net has a hard limit on the number of zerocopy skbs in flight. When reached, transmission stalls. Stalls cause latency, as well as head-of-line blocking of other flows that do not use zerocopy. Instead of stalling, revert to copy

Re: [PATCH net-next] vhost_net: do not stall on zerocopy depletion

On Fri, Sep 29, 2017 at 9:25 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Fri, Sep 29, 2017 at 3:38 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: >>> From: Willem

Re: [PATCH RFC 1/2] virtio_net: implement VIRTIO_CONFIG_S_NEEDS_RESET

On Tue, Aug 29, 2017 at 4:20 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Aug 29, 2017 at 04:07:58PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <will...@google.com> >> >> Implement the reset communication request defined in the VIRTIO 1.

Re: [PATCH net-next] virtio_net: implement VIRTIO_CONFIG_S_NEEDS_RESET

>> +static int virtnet_reset(struct virtnet_info *vi) >> +{ >> + struct virtio_device *dev = vi->vdev; >> + int ret; >> + >> + virtio_config_disable(dev); >> + dev->failed = dev->config->get_status(dev) & VIRTIO_CONFIG_S_FAILED; >> + virtnet_freeze_down(dev, true); >> +

Re: [PATCH net-next] virtio_net: implement VIRTIO_CONFIG_S_NEEDS_RESET

On Mon, Oct 16, 2017 at 11:31 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Oct 16, 2017 at 11:03:18AM -0400, Willem de Bruijn wrote: >> >> +static int virtnet_reset(struct virtnet_info *vi) >> >> +{ >> >> + struct virti

Re: [PATCH net-next] virtio_net: implement VIRTIO_CONFIG_S_NEEDS_RESET

On Mon, Oct 16, 2017 at 12:38 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Oct 16, 2017 at 12:04:57PM -0400, Willem de Bruijn wrote: >> On Mon, Oct 16, 2017 at 11:31 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Mon, Oct 16, 2017 at 11:03:18AM

[PATCH net-next] virtio_net: implement VIRTIO_CONFIG_S_NEEDS_RESET

From: Willem de Bruijn <will...@google.com> Implement the reset communication request defined in the VIRTIO 1.0 specification and introduces in Linux in commit c00bbcf862896 ("virtio: add VIRTIO_CONFIG_S_NEEDS_RESET device status bit"). Use the virtnet_reset function intr

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Tue, Aug 29, 2017 at 3:42 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Aug 29, 2017 at 03:35:38PM -0400, Willem de Bruijn wrote: >> By the way, I have had an unrelated patch outstanding for a while >> to have virtio-net support the VIRTIO_CONFIG_S_NEEDS_RESET

Re: [PATCH RFC 2/2] virtio_net: enable probing for NEEDS_RESET support

On Tue, Aug 29, 2017 at 4:16 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Aug 29, 2017 at 04:07:59PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <will...@google.com> >> >> Implement a mechanism to signal that a virtio device implements t

[PATCH RFC 2/2] virtio_net: enable probing for NEEDS_RESET support

From: Willem de Bruijn <will...@google.com> Implement a mechanism to signal that a virtio device implements the VIRTIO_CONFIG_S_NEEDS_RESET command. Testing for VIRTIO_CONFIG_S_NEEDS_RESET support by issuing the request and verifying the reset state would require an expensive state

Re: [virtio-dev] Re: packed ring layout proposal v3

On Mon, Sep 11, 2017 at 3:47 AM, Jason Wang wrote: > > > On 2017年09月10日 13:06, Michael S. Tsirkin wrote: >> >> This is an update from v2 version. >> Changes: >> - update event suppression mechanism >> - add wrap counter: DESC_WRAP flag in addition to >>DESC_DRIVER flag

Re: [PATCH net-next] vhost_net: do not stall on zerocopy depletion

On Thu, Sep 28, 2017 at 3:41 AM, Jason Wang <jasow...@redhat.com> wrote: > > > On 2017年09月28日 08:25, Willem de Bruijn wrote: >> >> From: Willem de Bruijn <will...@google.com> >> >> Vhost-net has a hard limit on the number of zerocopy skbs in flight.

Re: [PATCH net-next] vhost_net: do not stall on zerocopy depletion

On Fri, Sep 29, 2017 at 3:38 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <will...@google.com> >> >> Vhost-net has a hard limit on the number of zerocopy skbs in flig

Re: [PATCH net-next RFC 5/5] vhost_net: basic tx virtqueue batched processing

> @@ -461,6 +460,7 @@ static void handle_tx(struct vhost_net *net) > struct socket *sock; > struct vhost_net_ubuf_ref *uninitialized_var(ubufs); > bool zcopy, zcopy_used; > + int i, batched = VHOST_NET_BATCH; > > mutex_lock(>mutex); > sock =

Re: [PATCH net-next RFC 3/5] vhost: introduce vhost_add_used_idx()

>> > > @@ -199,6 +199,7 @@ int __vhost_get_vq_desc(struct vhost_virtqueue *vq, >> > > void vhost_discard_vq_desc(struct vhost_virtqueue *, int n); >> > > int vhost_vq_init_access(struct vhost_virtqueue *); >> > > +int vhost_add_used_idx(struct vhost_virtqueue *vq, int n); >> > > int

Re: [PATCH net-next] vhost_net: do not stall on zerocopy depletion

On Wed, Sep 27, 2017 at 8:25 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > From: Willem de Bruijn <will...@google.com> > > Vhost-net has a hard limit on the number of zerocopy skbs in flight. > When reached, transmission stalls. Stalls cause latency, a

Re: [PATCH net-next RFC 2/5] vhost: introduce helper to prefetch desc index

On Fri, Sep 22, 2017 at 4:02 AM, Jason Wang wrote: > This patch introduces vhost_prefetch_desc_indices() which could batch > descriptor indices fetching and used ring updating. This intends to > reduce the cache misses of indices fetching and updating and reduce > cache line

[PATCH net-next] vhost_net: do not stall on zerocopy depletion

From: Willem de Bruijn <will...@google.com> Vhost-net has a hard limit on the number of zerocopy skbs in flight. When reached, transmission stalls. Stalls cause latency, as well as head-of-line blocking of other flows that do not use zerocopy. Instead of stalling, revert to copy

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

>> Traffic shaping can introduce msec timescale latencies. >> >> The delay may actually be a useful signal. If the guest does not >> orphan skbs early, TSQ will throttle the socket causing host >> queue build up. >> >> But, if completions are queued in-order, unrelated flows may be >> throttled as

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Mon, Aug 21, 2017 at 8:33 AM, Jason Wang wrote: > > > On 2017年08月19日 14:38, Koichiro Den wrote: >> >> Facing the possible unbounded delay relying on freeing on xmit path, >> we also better to invoke and clear the upper layer zerocopy callback >> beforehand to keep them

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Sun, Aug 20, 2017 at 4:49 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Sat, Aug 19, 2017 at 2:38 AM, Koichiro Den <d...@klaipeden.com> wrote: >> Facing the possible unbounded delay relying on freeing on xmit path, >> we also better to invok

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

>> >> > We don't enable network watchdog on virtio but we could and maybe >> >> > should. >> >> >> >> Can you elaborate? >> > >> > The issue is that holding onto buffers for very long times makes guests >> > think they are stuck. This is funamentally because from guest point of >> > view this is a

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Fri, Aug 25, 2017 at 7:32 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Fri, Aug 25, 2017 at 06:44:36PM -0400, Willem de Bruijn wrote: >> >> >> > We don't enable network watchdog on virtio but we could and maybe >> >> >&g

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

>> > * as a generic solution, if we were to somehow overcome the safety issue, >> > track >> > the delay and do copy if some threshold is reached could be an answer, but >> > it's >> > hard for now.> * so things like the current vhost-net implementation of >> > deciding whether or not >> > to

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

> Please let me make sure if I understand it correctly: > * always do copy with skb_orphan_frags_rx as Willem mentioned in the earlier > post, before the xmit_skb as opposed to my original patch, is safe but too > costly so cannot be adopted. One more point about msg_zerocopy in the guest. This

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Tue, Aug 29, 2017 at 3:35 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Fri, Aug 25, 2017 at 9:03 PM, Willem de Bruijn > <willemdebruijn.ker...@gmail.com> wrote: >> On Fri, Aug 25, 2017 at 7:32 PM, Michael S. Tsirkin <m...@redhat.com> wrote:

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Thu, Aug 31, 2017 at 11:25 PM, Jason Wang <jasow...@redhat.com> wrote: > > > On 2017年08月31日 22:30, Willem de Bruijn wrote: >>> >>> Incomplete results at this stage, but I do see this correlation between >>> flows. It occurs even while not running out o

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

>>> This is not a 50/50 split, which impliesTw that some packets from the >>> large >>> packet flow are still converted to copying. Without the change the rate >>> without queue was 80k zerocopy vs 80k copy, so this choice of >>> (vq->num >> 2) appears too conservative. >>> >>> However, testing

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Tue, Aug 29, 2017 at 4:40 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Aug 29, 2017 at 03:53:08PM -0400, Willem de Bruijn wrote: >> On Tue, Aug 29, 2017 at 3:42 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Tue, Aug 29, 2017 at 03:35:38PM

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Mon, Sep 4, 2017 at 5:03 AM, Jason Wang <jasow...@redhat.com> wrote: > > > On 2017年09月02日 00:17, Willem de Bruijn wrote: >>>>> >>>>> This is not a 50/50 split, which impliesTw that some packets from the >>>>> large >>>>&

Re: [PATCH RFC 2/2] virtio_net: enable probing for NEEDS_RESET support

+ virtio-dev On Tue, Aug 29, 2017 at 4:38 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Aug 29, 2017 at 04:27:41PM -0400, Willem de Bruijn wrote: >> On Tue, Aug 29, 2017 at 4:16 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Tue, Aug 29, 2017

[PATCH RFC 0/2] virtio-net: implement reset request

From: Willem de Bruijn <will...@google.com> Implement VIRTIO_CONFIG_S_NEEDS_RESET (patch 1) and add a feature bit to signal support (patch 2) Further details in the individual patches. Willem de Bruijn (2): virtio_net: implement VIRTIO_CONFIG_S_NEEDS_RESET virtio_net: enable p

[PATCH RFC 1/2] virtio_net: implement VIRTIO_CONFIG_S_NEEDS_RESET

From: Willem de Bruijn <will...@google.com> Implement the reset communication request defined in the VIRTIO 1.0 specification and introduces in Linux in commit c00bbcf862896 ("virtio: add VIRTIO_CONFIG_S_NEEDS_RESET device status bit"). Since that patch, the virtio-net

Re: [PATCH net-next] virtio-net: invoke zerocopy callback on xmit path if no tx napi

On Tue, Aug 29, 2017 at 9:45 PM, Jason Wang <jasow...@redhat.com> wrote: > > > On 2017年08月30日 03:35, Willem de Bruijn wrote: >> >> On Fri, Aug 25, 2017 at 9:03 PM, Willem de Bruijn >> <willemdebruijn.ker...@gmail.com> wrote: >>> >>&g

Re: Possible unsafe usage of skb->cb in virtio-net

On Thu, Nov 2, 2017 at 10:01 PM, Michael S. Tsirkin wrote: > On Thu, Nov 02, 2017 at 11:40:36AM +, Ilya Lesokhin wrote: >> Hi, >> I've noticed that the virtio-net uses skb->cb. >> >> I don't know all the detail by my understanding is it caused problem with >> the mlx5 driver

Re: [PATCH net-next] virtio_net: implement VIRTIO_CONFIG_S_NEEDS_RESET

On Mon, Oct 16, 2017 at 11:44 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Oct 17, 2017 at 11:05:07AM +0800, Jason Wang wrote: >> >> >> On 2017年10月17日 06:34, Willem de Bruijn wrote: >> > On Mon, Oct 16, 2017 at 12:38 PM, Michael S. Tsirkin <m...

Re: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

On Thu, Dec 20, 2018 at 9:16 AM Ido Schimmel wrote: > > On Thu, Dec 20, 2018 at 09:04:25AM -0500, Willem de Bruijn wrote: > > On Thu, Dec 20, 2018 at 6:15 AM Ido Schimmel wrote: > > > > > > +Willem > > > > > > On Thu, Dec 20, 2018 at 08:45:40AM +

Re: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

On Thu, Dec 20, 2018 at 9:34 AM Willem de Bruijn wrote: > > On Thu, Dec 20, 2018 at 9:16 AM Ido Schimmel wrote: > > > > On Thu, Dec 20, 2018 at 09:04:25AM -0500, Willem de Bruijn wrote: > > > On Thu, Dec 20, 2018 at 6:15 AM Ido Schimmel wrote: > > > > >

Re: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

On Thu, Dec 20, 2018 at 6:15 AM Ido Schimmel wrote: > > +Willem > > On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote: > > Folks, > > > > I got this warning today. I cant tell when and why this happened, so I do > > not know yet how to reproduce. > > Maybe someone has a quick

Re: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel wrote: > > On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote: > > On 20.12.2018 10:12, Ido Schimmel wrote: > > > +Willem > > > > > > On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote: > > >> Folks, > > >> > > >>

Re: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

On Fri, Dec 21, 2018 at 1:45 AM Christian Borntraeger wrote: > > > > On 20.12.2018 18:23, Willem de Bruijn wrote: > > On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel wrote: > >> > >> On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote: >

Re: [PATCH net-next V2] virtio_net: ethtool tx napi configuration

; disabled after skb_xmit_done() but before the napi > > Link: https://patchwork.ozlabs.org/patch/948149/ > Suggested-by: Jason Wang > Signed-off-by: Willem de Bruijn > Signed-off-by: Jason Wang > --- > Changes from V1: > - try to synchronize with datapath to allow changing

Re: [PATCH net] virtio-net: Skip set_features on non-cvq devices

On Fri, Dec 20, 2019 at 4:22 PM Alistair Delva wrote: > > On devices without control virtqueue support, such as the virtio_net > implementation in crosvm[1], attempting to configure LRO will panic the > kernel: > > kernel BUG at drivers/net/virtio_net.c:1591! > invalid opcode: [#1] PREEMPT

Re: [PATCH net] virtio-net: Skip set_features on non-cvq devices

On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin wrote: > > On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote: > > On Fri, Dec 20, 2019 at 4:22 PM Alistair Delva wrote: > > > > > > On devices without control virtqueue support, such as the v

Re: [PATCH net] virtio-net: Skip set_features on non-cvq devices

On Sun, Dec 22, 2019 at 9:57 AM Michael S. Tsirkin wrote: > > On Sun, Dec 22, 2019 at 09:21:43AM -0500, Willem de Bruijn wrote: > > On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin wrote: > > > > > > On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote

Re: [PATCH net] virtio-net: Skip set_features on non-cvq devices

On Sun, Dec 22, 2019 at 4:12 PM Michael S. Tsirkin wrote: > > On Sun, Dec 22, 2019 at 10:54:23AM -0500, Willem de Bruijn wrote: > > On Sun, Dec 22, 2019 at 9:57 AM Michael S. Tsirkin wrote: > > > > > > On Sun, Dec 22, 2019 at 09:21:43AM -0500, Willem de Bruijn wrote

Re: [PATCH net] virtio_net: CTRL_GUEST_OFFLOADS depends on CTRL_VQ

On Mon, Dec 23, 2019 at 3:22 PM Alistair Delva wrote: > > On Mon, Dec 23, 2019 at 12:12 PM Willem de Bruijn > wrote: > > > > On Mon, Dec 23, 2019 at 2:56 PM Willem de Bruijn > > wrote: > > > > > > 00fffe0ff0 DR7: 0400 > > > &g

Re: [PATCH v3] virtio: Work around frames incorrectly marked as gso

On Mon, Feb 24, 2020 at 8:26 AM wrote: > > From: Anton Ivanov > > Some of the locally generated frames marked as GSO which > arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no > fragments (data_len = 0) and length significantly shorter > than the MTU (752 in my experiments). Do we

Re: [PATCH v3] virtio: Work around frames incorrectly marked as gso

On Mon, Feb 24, 2020 at 2:55 PM Anton Ivanov wrote: > > On 24/02/2020 19:27, Willem de Bruijn wrote: > > On Mon, Feb 24, 2020 at 8:26 AM wrote: > >> > >> From: Anton Ivanov > >> > >> Some of the locally generated frames marked as GSO whi

Re: [PATCH v3] virtio: Work around frames incorrectly marked as gso

> An skb_dump() + dump_stack() when the packet socket gets such a > packet may point us to the root cause and fix that. > >>> > >>> We tried dump stack, it was not informative - it was just the recvmmsg > >>> call stack coming from the UML until it hits the relevant recv bit in > >>>

Re: [PATCH v3] virtio: Work around frames incorrectly marked as gso

On Mon, Feb 24, 2020 at 4:00 PM Anton Ivanov wrote: > > On 24/02/2020 20:20, Willem de Bruijn wrote: > > On Mon, Feb 24, 2020 at 2:55 PM Anton Ivanov > > wrote: > >> On 24/02/2020 19:27, Willem de Bruijn wrote: > >>> On Mon, Feb 24, 2020 at 8:

Re: [PATCH net] virtio_net: CTRL_GUEST_OFFLOADS depends on CTRL_VQ

__vfs_write+0x3e/0x190 > > ? __sb_start_write+0x6d/0xd0 > > vfs_write+0xd3/0x190 > > ksys_write+0x68/0xd0 > > __ia32_sys_write+0x14/0x20 > > do_fast_syscall_32+0x86/0xe0 > > entry_SYSENTER_compat+0x7c/0x8e > > > > A similar crash will likely tri

Re: [PATCH net] virtio_net: CTRL_GUEST_OFFLOADS depends on CTRL_VQ

On Mon, Dec 23, 2019 at 2:56 PM Willem de Bruijn wrote: > > 00fffe0ff0 DR7: 0400 > > > Call Trace: > > > ? preempt_count_add+0x58/0xb0 > > > ? _raw_spin_lock_irqsave+0x36/0x70 > > > ? _raw_spin_unlock_irqrestore+0x1a/0x40 > > >

Re: [PATCH net-next v3] virtio-net: ethtool configurable RXCSUM

S. > > If Rx checksum is disabled, LRO should also be disabled. > > Cc: Michael S. Tsirkin > Cc: Jason Wang > Cc: Willem de Bruijn > Signed-off-by: Tonghao Zhang > Acked-by: Michael S. Tsirkin Acked-by: Willem de Bruijn I had to recall why we cannot just rely on dev->

Re: [PATCH net-next v2] virtio-net: ethtool configurable RXCSUM

On Fri, Oct 9, 2020 at 10:10 PM Tonghao Zhang wrote: > > On Fri, Oct 9, 2020 at 9:49 PM Willem de Bruijn > wrote: > > > > On Thu, Oct 8, 2020 at 9:19 PM Tonghao Zhang > > wrote: > > > > > > On Wed, Sep 30, 2020 at 6:05 PM Willem de Bruijn > >

Re: [PATCH net-next v2] virtio-net: ethtool configurable RXCSUM

On Thu, Oct 8, 2020 at 9:19 PM Tonghao Zhang wrote: > > On Wed, Sep 30, 2020 at 6:05 PM Willem de Bruijn > wrote: > > > > On Wed, Sep 30, 2020 at 4:05 AM wrote: > > > > > > From: Tonghao Zhang > > > > > > Allow user configuring RXCS

Re: [PATCH net v2] virtio-net: don't disable guest csum when disable LRO

> Fixes: a02e8964eaf9 ("virtio-net: ethtool configurable LRO") > Cc: Michael S. Tsirkin > Cc: Jason Wang > Cc: Willem de Bruijn > Signed-off-by: Tonghao Zhang Acked-by: Willem de Bruijn ___ Virtualization mailing list V

Re: [PATCH net v2] virtio-net: don't disable guest csum when disable LRO

On Tue, Sep 29, 2020 at 9:56 AM Tonghao Zhang wrote: > > On Tue, Sep 29, 2020 at 3:32 PM Willem de Bruijn > wrote: > > > > On Tue, Sep 29, 2020 at 4:00 AM wrote: > > > > > > From: Tonghao Zhang > > > > > > Open vSwitch and

Re: [PATCH 1/2] virtio-net: don't disable guest csum when disable LRO

ot;virtio-net: ethtool configurable LRO"). If this is a fix, it should target [PATCH net] separately from the second patch in the patchset, which is a new feature and targets [PATCH net-next]. They can arguably target net-next together, but then it should not have a fixes tag. > Cc: Michae

Re: [PATCH net-next v2] virtio-net: ethtool configurable RXCSUM

On Wed, Sep 30, 2020 at 4:05 AM wrote: > > From: Tonghao Zhang > > Allow user configuring RXCSUM separately with ethtool -K, > reusing the existing virtnet_set_guest_offloads helper > that configures RXCSUM for XDP. This is conditional on > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS. > > If Rx checksum is

Re: [PATCH 2/2] virtio-net: ethtool configurable RXCSUM

On Mon, Sep 28, 2020 at 5:42 AM wrote: > > From: Tonghao Zhang > > Allow user configuring RXCSUM separately with ethtool -K, > reusing the existing virtnet_set_guest_offloads helper > that configures RXCSUM for XDP. This is conditional on > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS. > > Cc: Michael S.

Re: [PATCH net v2] virtio-net: don't disable guest csum when disable LRO

rops the forwarding performance. > > > > > > > > Fixes: a02e8964eaf9 ("virtio-net: ethtool configurable LRO") > > > > Cc: Michael S. Tsirkin > > > > Cc: Jason Wang > > > > Cc: Willem de Bruijn > > > > Signed-off-by

Re: [PATCH net v2] virtio-net: don't disable guest csum when disable LRO

ce. I had focused on the code previously. The s/w checksum verification cost is significant in a VM with traffic to local destinations. A bridge does not verify transport layer checksums OTOH? > Fixes: a02e8964eaf9 ("virtio-net: ethtool configurable LRO") > Cc: Michael S. Tsirkin > C

Re: [PATCH rfc 2/3] virtio-net: support receive timestamp

On Tue, Dec 29, 2020 at 4:23 AM Jason Wang wrote: > > > > - Original Message - > > On Mon, Dec 28, 2020 at 7:55 PM Michael S. Tsirkin wrote: > > > > > > On Mon, Dec 28, 2020 at 02:30:31PM -0500, Willem de Bruijn wrote: > > > > On

Re: [PATCH net v5 1/2] vhost_net: fix ubuf refcount incorrectly when sendmsg fails

On Sun, Dec 27, 2020 at 6:26 AM Michael S. Tsirkin wrote: > > On Fri, Dec 25, 2020 at 03:24:25PM +0800, wangyunjian wrote: > > From: Yunjian Wang > > > > Currently the vhost_zerocopy_callback() maybe be called to decrease > > the refcount when sendmsg fails in tun. The error handling in vhost >

Re: [PATCH rfc 0/3] virtio-net: add tx-hash, rx-tstamp and tx-tstamp

On Mon, Dec 28, 2020 at 8:15 PM Willem de Bruijn wrote: > > On Mon, Dec 28, 2020 at 7:47 PM Michael S. Tsirkin wrote: > > > > On Mon, Dec 28, 2020 at 02:51:09PM -0500, Willem de Bruijn wrote: > > > On Mon, Dec 28, 2020 at 12:29 PM Michael S. Tsirkin > > > w

Re: [PATCH net v2] tun: fix ubuf refcount incorrectly on error path

On Wed, Dec 9, 2020 at 8:03 AM wangyunjian wrote: > > From: Yunjian Wang > > After setting callback for ubuf_info of skb, the callback > (vhost_net_zerocopy_callback) will be called to decrease > the refcount when freeing skb. But when an exception occurs With exception, you mean if

Re: [PATCH net v2] tun: fix ubuf refcount incorrectly on error path

> > > afterwards, the error handling in vhost handle_tx() will try to > > > decrease the same refcount again. This is wrong and fix this by delay > > > copying ubuf_info until we're sure there's no errors. > > > > I think the right approach is to address this in the error paths, rather > > than >

  1   2   3   >