search for: zerocopy

...pectedly long. >>> I think the total amount of time for busy polling is bounded. If I was >>> wrong, it should be a bug somewhere. >> Consider this kind of scenario: >> 0. Set 100us busypoll for example. >> 1. handle_tx() runs busypoll. >> 2. Something like zerocopy queues tx_work within 100us. >> 3. busypoll exits and call handle_tx() again. >> 4. Repeat 1-3. >> >> In this case handle_tx() does not process packets but busypoll >> essentially runs beyond 100us without endtime memorized. This may be >> just a theoretical prob...

...pectedly long. >>> I think the total amount of time for busy polling is bounded. If I was >>> wrong, it should be a bug somewhere. >> Consider this kind of scenario: >> 0. Set 100us busypoll for example. >> 1. handle_tx() runs busypoll. >> 2. Something like zerocopy queues tx_work within 100us. >> 3. busypoll exits and call handle_tx() again. >> 4. Repeat 1-3. >> >> In this case handle_tx() does not process packets but busypoll >> essentially runs beyond 100us without endtime memorized. This may be >> just a theoretical prob...

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 of zerocopy descriptors, >> which I cannot yet explain. >> >> Running two threads in a guest, each with a udp socket, each >> sending up to 100 datagrams, or until EAGAIN, every msec. >> >> Sender A sends 1B datagrams. >> Sender B sends VHOST_GOODCOPY_LEN, which is eno...

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 of zerocopy descriptors, >> which I cannot yet explain. >> >> Running two threads in a guest, each with a udp socket, each >> sending up to 100 datagrams, or until EAGAIN, every msec. >> >> Sender A sends 1B datagrams. >> Sender B sends VHOST_GOODCOPY_LEN, which is eno...

...total amount of time for busy polling is bounded. If I was >>>>> wrong, it should be a bug somewhere. >>>> Consider this kind of scenario: >>>> 0. Set 100us busypoll for example. >>>> 1. handle_tx() runs busypoll. >>>> 2. Something like zerocopy queues tx_work within 100us. >>>> 3. busypoll exits and call handle_tx() again. >>>> 4. Repeat 1-3. >>>> >>>> In this case handle_tx() does not process packets but busypoll >>>> essentially runs beyond 100us without endtime memorized. This...

...memorizing it busypoll >> can run unexpectedly long. > > I think the total amount of time for busy polling is bounded. If I was > wrong, it should be a bug somewhere. Consider this kind of scenario: 0. Set 100us busypoll for example. 1. handle_tx() runs busypoll. 2. Something like zerocopy queues tx_work within 100us. 3. busypoll exits and call handle_tx() again. 4. Repeat 1-3. In this case handle_tx() does not process packets but busypoll essentially runs beyond 100us without endtime memorized. This may be just a theoretical problem, but I was worried that more code to poll tx queu...

...memorizing it busypoll >> can run unexpectedly long. > > I think the total amount of time for busy polling is bounded. If I was > wrong, it should be a bug somewhere. Consider this kind of scenario: 0. Set 100us busypoll for example. 1. handle_tx() runs busypoll. 2. Something like zerocopy queues tx_work within 100us. 3. busypoll exits and call handle_tx() again. 4. Repeat 1-3. In this case handle_tx() does not process packets but busypoll essentially runs beyond 100us without endtime memorized. This may be just a theoretical problem, but I was worried that more code to poll tx queu...

On Fri, Sep 29, 2017 at 3:38 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <willemb at 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-based transmission. >> >> Tested by sending two udp flows from guest...

On Fri, Sep 29, 2017 at 3:38 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <willemb at 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-based transmission. >> >> Tested by sending two udp flows from guest...

...Thu, Aug 31, 2017 at 11:25 PM, Jason Wang <jasowang at 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 of zerocopy descriptors, >>> which I cannot yet explain. >>> >>> Running two threads in a guest, each with a udp socket, each >>> sending up to 100 datagrams, or until EAGAIN, every msec. >>> >>> Sender A sends 1B datagrams. >>> Sender B sends VHOS...

On Mon, Feb 06, 2023 at 07:06:32AM +0000, Arseniy Krasnov wrote: >To use this option pass '--zc' parameter: --zerocopy or --zero-copy maybe better follow what we did with the other parameters :-) > >./vsock_perf --zc --sender <cid> --port <port> --bytes <bytes to send> > >With this option MSG_ZEROCOPY flag will be passed to the 'send()' call. > >Signed-off-by: Arseniy K...

Vhost_net was known to suffer from HOL[1] issues which is not easy to fix. Several downstream disable the feature by default. What's more, the datapath was split and datacopy path got the support of batching and XDP support recently which makes it faster than zerocopy part for small packets transmission. It looks to me that disable zerocopy by default is more appropriate. It cold be enabled by default again in the future if we fix the above issues. [1] https://patchwork.kernel.org/patch/3787671/ Signed-off-by: Jason Wang <jasowang at redhat.com> --- dr...

From: Willem de Bruijn <willemb at 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-based transmission. Tested by sending two udp flows from guest to host, one with payload of VHOST_GOODCOPY_LEN, th...

From: Willem de Bruijn <willemb at 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-based transmission. Tested by sending two udp flows from guest to host, one with payload of VHOST_GOODCOPY_LEN, th...

From: Willem de Bruijn <willemb at 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-based transmission. Tested by sending two udp flows from guest to host, one with payload of VHOST_GOODCOPY_LEN, th...

From: Willem de Bruijn <willemb at 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-based transmission. Tested by sending two udp flows from guest to host, one with payload of VHOST_GOODCOPY_LEN, th...

>>> 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 with (vq->num >> 1) was not as effective at mitigating >>> stalls. I did not save that data, unfortunately. Can run more tests on >>> f...

>>> 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 with (vq->num >> 1) was not as effective at mitigating >>> stalls. I did not save that data, unfortunately. Can run more tests on >>> f...

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 >>>> 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 with (vq->num >> 1) was not as effective at mitigating >>>> stalls. I did not save that data, unfortunately. Can run more tests o...

...gt;>> can run unexpectedly long. >> I think the total amount of time for busy polling is bounded. If I was >> wrong, it should be a bug somewhere. > Consider this kind of scenario: > 0. Set 100us busypoll for example. > 1. handle_tx() runs busypoll. > 2. Something like zerocopy queues tx_work within 100us. > 3. busypoll exits and call handle_tx() again. > 4. Repeat 1-3. > > In this case handle_tx() does not process packets but busypoll > essentially runs beyond 100us without endtime memorized. This may be > just a theoretical problem, but I was worried t...