| Message ID | 20230911202234.1932024-1-avkrasnov@salutedevices.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | vsock/virtio/vhost: MSG_ZEROCOPY preparations | expand |
Hello Stefano, On 14.09.2023 17:07, Stefano Garzarella wrote: > Hi Arseniy, > > On Mon, Sep 11, 2023 at 11:22:30PM +0300, Arseniy Krasnov wrote: >> Hello, >> >> this patchset is first of three parts of another big patchset for >> MSG_ZEROCOPY flag support: >> https://lore.kernel.org/netdev/20230701063947.3422088-1-AVKrasnov@sberdevices.ru/ >> >> During review of this series, Stefano Garzarella <sgarzare@redhat.com> >> suggested to split it for three parts to simplify review and merging: >> >> 1) virtio and vhost updates (for fragged skbs) <--- this patchset >> 2) AF_VSOCK updates (allows to enable MSG_ZEROCOPY mode and read >> tx completions) and update for Documentation/. >> 3) Updates for tests and utils. >> >> This series enables handling of fragged skbs in virtio and vhost parts. >> Newly logic won't be triggered, because SO_ZEROCOPY options is still >> impossible to enable at this moment (next bunch of patches from big >> set above will enable it). >> >> I've included changelog to some patches anyway, because there were some >> comments during review of last big patchset from the link above. > > Thanks, I left some comments on patch 4, the others LGTM. > Sorry to not having spotted them before, but moving > virtio_transport_alloc_skb() around the file, made the patch a little > confusing and difficult to review. Sure, no problem, I'll fix them! Thanks for review. > > In addition, I started having failures of test 14 (server: host, > client: guest), so I looked better to see if there was anything wrong, > but it fails me even without this series applied. > > It happens to me intermittently (~30%), does it happen to you? > Can you take a look at it? Yes! sometime ago I also started to get fails of this test, not ~30%, significantly rare, but it depends on environment I guess, anyway I'm going to look at this on the next few days Thanks, Arseniy > > host$ ./vsock_test --mode=server --control-port=12345 --peer-cid=4 > ... > 14 - SOCK_STREAM virtio skb merge...expected recv(2) returns 8 bytes, got 3 > > guest$ ./vsock_test --mode=client --control-host=192.168.133.2 --control-port=12345 --peer-cid=2 > > Thanks, > Stefano >
Hi Arseniy, On Mon, Sep 11, 2023 at 11:22:30PM +0300, Arseniy Krasnov wrote: >Hello, > >this patchset is first of three parts of another big patchset for >MSG_ZEROCOPY flag support: >https://lore.kernel.org/netdev/20230701063947.3422088-1-AVKrasnov@sberdevices.ru/ > >During review of this series, Stefano Garzarella <sgarzare@redhat.com> >suggested to split it for three parts to simplify review and merging: > >1) virtio and vhost updates (for fragged skbs) <--- this patchset >2) AF_VSOCK updates (allows to enable MSG_ZEROCOPY mode and read > tx completions) and update for Documentation/. >3) Updates for tests and utils. > >This series enables handling of fragged skbs in virtio and vhost parts. >Newly logic won't be triggered, because SO_ZEROCOPY options is still >impossible to enable at this moment (next bunch of patches from big >set above will enable it). > >I've included changelog to some patches anyway, because there were some >comments during review of last big patchset from the link above. Thanks, I left some comments on patch 4, the others LGTM. Sorry to not having spotted them before, but moving virtio_transport_alloc_skb() around the file, made the patch a little confusing and difficult to review. In addition, I started having failures of test 14 (server: host, client: guest), so I looked better to see if there was anything wrong, but it fails me even without this series applied. It happens to me intermittently (~30%), does it happen to you? Can you take a look at it? host$ ./vsock_test --mode=server --control-port=12345 --peer-cid=4 ... 14 - SOCK_STREAM virtio skb merge...expected recv(2) returns 8 bytes, got 3 guest$ ./vsock_test --mode=client --control-host=192.168.133.2 --control-port=12345 --peer-cid=2 Thanks, Stefano
On Thu, Sep 14, 2023 at 05:05:17PM +0300, Arseniy Krasnov wrote: >Hello Stefano, > >On 14.09.2023 17:07, Stefano Garzarella wrote: >> Hi Arseniy, >> >> On Mon, Sep 11, 2023 at 11:22:30PM +0300, Arseniy Krasnov wrote: >>> Hello, >>> >>> this patchset is first of three parts of another big patchset for >>> MSG_ZEROCOPY flag support: >>> https://lore.kernel.org/netdev/20230701063947.3422088-1-AVKrasnov@sberdevices.ru/ >>> >>> During review of this series, Stefano Garzarella <sgarzare@redhat.com> >>> suggested to split it for three parts to simplify review and merging: >>> >>> 1) virtio and vhost updates (for fragged skbs) <--- this patchset >>> 2) AF_VSOCK updates (allows to enable MSG_ZEROCOPY mode and read >>> tx completions) and update for Documentation/. >>> 3) Updates for tests and utils. >>> >>> This series enables handling of fragged skbs in virtio and vhost parts. >>> Newly logic won't be triggered, because SO_ZEROCOPY options is still >>> impossible to enable at this moment (next bunch of patches from big >>> set above will enable it). >>> >>> I've included changelog to some patches anyway, because there were some >>> comments during review of last big patchset from the link above. >> >> Thanks, I left some comments on patch 4, the others LGTM. >> Sorry to not having spotted them before, but moving >> virtio_transport_alloc_skb() around the file, made the patch a little >> confusing and difficult to review. > >Sure, no problem, I'll fix them! Thanks for review. > >> >> In addition, I started having failures of test 14 (server: host, >> client: guest), so I looked better to see if there was anything wrong, >> but it fails me even without this series applied. >> >> It happens to me intermittently (~30%), does it happen to you? >> Can you take a look at it? > >Yes! sometime ago I also started to get fails of this test, not ~30%, >significantly rare, but it depends on environment I guess, anyway I'm going to >look at this on the next few days Maybe it's just a timing issue in the test, indeed we are expecting 8 bytes but we received only 3 plus the 2 bytes we received before it seems exactly the same bytes we send with the first `send(fd, HELLO_STR, strlen(HELLO_STR), 0);` Since it is a stream socket, it could happen, so we should retry the recv() or just use MSG_WAITALL. Applying the following patch fixed the issue for me (15 mins without errors for now): diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c index 90718c2fd4ea..7b0fed9fc58d 100644 --- a/tools/testing/vsock/vsock_test.c +++ b/tools/testing/vsock/vsock_test.c @@ -1129,7 +1129,7 @@ static void test_stream_virtio_skb_merge_server(const struct test_opts *opts) control_expectln("SEND0"); /* Read skbuff partially. */ - res = recv(fd, buf, 2, 0); + res = recv(fd, buf, 2, MSG_WAITALL); if (res != 2) { fprintf(stderr, "expected recv(2) returns 2 bytes, got %zi\n", res); exit(EXIT_FAILURE); @@ -1138,7 +1138,7 @@ static void test_stream_virtio_skb_merge_server(const struct test_opts *opts) control_writeln("REPLY0"); control_expectln("SEND1"); - res = recv(fd, buf + 2, sizeof(buf) - 2, 0); + res = recv(fd, buf + 2, 8, MSG_WAITALL); if (res != 8) { fprintf(stderr, "expected recv(2) returns 8 bytes, got %zi\n", res); exit(EXIT_FAILURE); I will check better all the cases and send a patch upstream. Anyway it looks just an issue in our test suite :-) Stefano > >Thanks, Arseniy > >> >> host$ ./vsock_test --mode=server --control-port=12345 --peer-cid=4 >> ... >> 14 - SOCK_STREAM virtio skb merge...expected recv(2) returns 8 bytes, got 3 >> >> guest$ ./vsock_test --mode=client --control-host=192.168.133.2 --control-port=12345 --peer-cid=2 >> >> Thanks, >> Stefano >> >
On 14.09.2023 18:34, Stefano Garzarella wrote: > On Thu, Sep 14, 2023 at 05:05:17PM +0300, Arseniy Krasnov wrote: >> Hello Stefano, >> >> On 14.09.2023 17:07, Stefano Garzarella wrote: >>> Hi Arseniy, >>> >>> On Mon, Sep 11, 2023 at 11:22:30PM +0300, Arseniy Krasnov wrote: >>>> Hello, >>>> >>>> this patchset is first of three parts of another big patchset for >>>> MSG_ZEROCOPY flag support: >>>> https://lore.kernel.org/netdev/20230701063947.3422088-1-AVKrasnov@sberdevices.ru/ >>>> >>>> During review of this series, Stefano Garzarella <sgarzare@redhat.com> >>>> suggested to split it for three parts to simplify review and merging: >>>> >>>> 1) virtio and vhost updates (for fragged skbs) <--- this patchset >>>> 2) AF_VSOCK updates (allows to enable MSG_ZEROCOPY mode and read >>>> tx completions) and update for Documentation/. >>>> 3) Updates for tests and utils. >>>> >>>> This series enables handling of fragged skbs in virtio and vhost parts. >>>> Newly logic won't be triggered, because SO_ZEROCOPY options is still >>>> impossible to enable at this moment (next bunch of patches from big >>>> set above will enable it). >>>> >>>> I've included changelog to some patches anyway, because there were some >>>> comments during review of last big patchset from the link above. >>> >>> Thanks, I left some comments on patch 4, the others LGTM. >>> Sorry to not having spotted them before, but moving >>> virtio_transport_alloc_skb() around the file, made the patch a little >>> confusing and difficult to review. >> >> Sure, no problem, I'll fix them! Thanks for review. >> >>> >>> In addition, I started having failures of test 14 (server: host, >>> client: guest), so I looked better to see if there was anything wrong, >>> but it fails me even without this series applied. >>> >>> It happens to me intermittently (~30%), does it happen to you? >>> Can you take a look at it? >> >> Yes! sometime ago I also started to get fails of this test, not ~30%, >> significantly rare, but it depends on environment I guess, anyway I'm going to >> look at this on the next few days > > Maybe it's just a timing issue in the test, indeed we are expecting 8 > bytes but we received only 3 plus the 2 bytes we received before it > seems exactly the same bytes we send with the first > `send(fd, HELLO_STR, strlen(HELLO_STR), 0);` > > Since it is a stream socket, it could happen, so we should retry > the recv() or just use MSG_WAITALL. > > Applying the following patch fixed the issue for me (15 mins without > errors for now): > > diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c > index 90718c2fd4ea..7b0fed9fc58d 100644 > --- a/tools/testing/vsock/vsock_test.c > +++ b/tools/testing/vsock/vsock_test.c > @@ -1129,7 +1129,7 @@ static void test_stream_virtio_skb_merge_server(const struct test_opts *opts) > control_expectln("SEND0"); > > /* Read skbuff partially. */ > - res = recv(fd, buf, 2, 0); > + res = recv(fd, buf, 2, MSG_WAITALL); > if (res != 2) { > fprintf(stderr, "expected recv(2) returns 2 bytes, got %zi\n", res); > exit(EXIT_FAILURE); > @@ -1138,7 +1138,7 @@ static void test_stream_virtio_skb_merge_server(const struct test_opts *opts) > control_writeln("REPLY0"); > control_expectln("SEND1"); > > - res = recv(fd, buf + 2, sizeof(buf) - 2, 0); > + res = recv(fd, buf + 2, 8, MSG_WAITALL); > if (res != 8) { > fprintf(stderr, "expected recv(2) returns 8 bytes, got %zi\n", res); > exit(EXIT_FAILURE); > > I will check better all the cases and send a patch upstream. Agree, I think this will fix it! Thanks, Arseniy > > Anyway it looks just an issue in our test suite :-) > > Stefano > >> >> Thanks, Arseniy >> >>> >>> host$ ./vsock_test --mode=server --control-port=12345 --peer-cid=4 >>> ... >>> 14 - SOCK_STREAM virtio skb merge...expected recv(2) returns 8 bytes, got 3 >>> >>> guest$ ./vsock_test --mode=client --control-host=192.168.133.2 --control-port=12345 --peer-cid=2 >>> >>> Thanks, >>> Stefano >>> >> >