All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arseny Krasnov <arseny.krasnov@kaspersky.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Norbert Slusarek <nslusarek@gmx.net>,
	Andra Paraschiv <andraprs@amazon.com>,
	Colin Ian King <colin.king@canonical.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"oxffffaa@gmail.com" <oxffffaa@gmail.com>
Subject: Re: [PATCH v11 11/18] virtio/vsock: dequeue callback for SOCK_SEQPACKET
Date: Fri, 18 Jun 2021 18:04:37 +0300	[thread overview]
Message-ID: <bb323125-f802-1d16-7530-6e4f4abb00a6@kaspersky.com> (raw)
In-Reply-To: <20210618134423.mksgnbmchmow4sgh@steredhat.lan>


On 18.06.2021 16:44, Stefano Garzarella wrote:
> Hi Arseny,
> the series looks great, I have just a question below about 
> seqpacket_dequeue.
>
> I also sent a couple a simple fixes, it would be great if you can review 
> them: 
> https://lore.kernel.org/netdev/20210618133526.300347-1-sgarzare@redhat.com/
>
>
> On Fri, Jun 11, 2021 at 02:12:38PM +0300, Arseny Krasnov wrote:
>> Callback fetches RW packets from rx queue of socket until whole record
>> is copied(if user's buffer is full, user is not woken up). This is done
>> to not stall sender, because if we wake up user and it leaves syscall,
>> nobody will send credit update for rest of record, and sender will wait
>> for next enter of read syscall at receiver's side. So if user buffer is
>> full, we just send credit update and drop data.
>>
>> Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>
>> ---
>> v10 -> v11:
>> 1) 'msg_count' field added to count current number of EORs.
>> 2) 'msg_ready' argument removed from callback.
>> 3) If 'memcpy_to_msg()' failed during copy loop, there will be
>>    no next attempts to copy data, rest of record will be freed.
>>
>> include/linux/virtio_vsock.h            |  5 ++
>> net/vmw_vsock/virtio_transport_common.c | 84 +++++++++++++++++++++++++
>> 2 files changed, 89 insertions(+)
>>
>> diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
>> index dc636b727179..1d9a302cb91d 100644
>> --- a/include/linux/virtio_vsock.h
>> +++ b/include/linux/virtio_vsock.h
>> @@ -36,6 +36,7 @@ struct virtio_vsock_sock {
>> 	u32 rx_bytes;
>> 	u32 buf_alloc;
>> 	struct list_head rx_queue;
>> +	u32 msg_count;
>> };
>>
>> struct virtio_vsock_pkt {
>> @@ -80,6 +81,10 @@ virtio_transport_dgram_dequeue(struct vsock_sock *vsk,
>> 			       struct msghdr *msg,
>> 			       size_t len, int flags);
>>
>> +ssize_t
>> +virtio_transport_seqpacket_dequeue(struct vsock_sock *vsk,
>> +				   struct msghdr *msg,
>> +				   int flags);
>> s64 virtio_transport_stream_has_data(struct vsock_sock *vsk);
>> s64 virtio_transport_stream_has_space(struct vsock_sock *vsk);
>>
>> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>> index ad0d34d41444..1e1df19ec164 100644
>> --- a/net/vmw_vsock/virtio_transport_common.c
>> +++ b/net/vmw_vsock/virtio_transport_common.c
>> @@ -393,6 +393,78 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
>> 	return err;
>> }
>>
>> +static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk,
>> +						 struct msghdr *msg,
>> +						 int flags)
>> +{
>> +	struct virtio_vsock_sock *vvs = vsk->trans;
>> +	struct virtio_vsock_pkt *pkt;
>> +	int dequeued_len = 0;
>> +	size_t user_buf_len = msg_data_left(msg);
>> +	bool copy_failed = false;
>> +	bool msg_ready = false;
>> +
>> +	spin_lock_bh(&vvs->rx_lock);
>> +
>> +	if (vvs->msg_count == 0) {
>> +		spin_unlock_bh(&vvs->rx_lock);
>> +		return 0;
>> +	}
>> +
>> +	while (!msg_ready) {
>> +		pkt = list_first_entry(&vvs->rx_queue, struct virtio_vsock_pkt, list);
>> +
>> +		if (!copy_failed) {
>> +			size_t pkt_len;
>> +			size_t bytes_to_copy;
>> +
>> +			pkt_len = (size_t)le32_to_cpu(pkt->hdr.len);
>> +			bytes_to_copy = min(user_buf_len, pkt_len);
>> +
>> +			if (bytes_to_copy) {
>> +				int err;
>> +
>> +				/* sk_lock is held by caller so no one else can dequeue.
>> +				 * Unlock rx_lock since memcpy_to_msg() may sleep.
>> +				 */
>> +				spin_unlock_bh(&vvs->rx_lock);
>> +
>> +				err = memcpy_to_msg(msg, pkt->buf, bytes_to_copy);
>> +				if (err) {
>> +					/* Copy of message failed, set flag to skip
>> +					 * copy path for rest of fragments. Rest of
>> +					 * fragments will be freed without copy.
>> +					 */
>> +					copy_failed = true;
>> +					dequeued_len = err;
> If we fail to copy the message we will discard the entire packet.
> Is it acceptable for the user point of view, or we should leave the 
> packet in the queue and the user can retry, maybe with a different 
> buffer?
>
> Then we can remove the packets only when we successfully copied all the 
> fragments.
>
> I'm not sure make sense, maybe better to check also other 
> implementations :-)
>
> Thanks,
> Stefano

Understand, i'll check it on weekend, anyway I think it is

not critical for implementation.


I have another question: may be it is useful to research for

approach where packets are not queued until whole message

is received, but copied to user's buffer thus freeing memory.

(like previous implementation, of course with solution of problem

where part of message still in queue, while reader was woken

by timeout or signal).

I think it is better, because  in current version, sender may set

'peer_alloc_buf' to  for example 1MB, so at receiver we get

1MB of 'kmalloc()' memory allocated, while having user's buffer

to copy data there or drop it(if user's buffer is full). This way

won't change spec(e.g. no message id or SEQ_BEGIN will be added).


What do You think?

>
>> +				} else {
>> +					user_buf_len -= bytes_to_copy;
>> +				}
>> +
>> +				spin_lock_bh(&vvs->rx_lock);
>> +			}
>> +
>> +			if (dequeued_len >= 0)
>> +				dequeued_len += pkt_len;
>> +		}
>> +
>> +		if (le32_to_cpu(pkt->hdr.flags) & VIRTIO_VSOCK_SEQ_EOR) {
>> +			msg_ready = true;
>> +			vvs->msg_count--;
>> +		}
>> +
>> +		virtio_transport_dec_rx_pkt(vvs, pkt);
>> +		list_del(&pkt->list);
>> +		virtio_transport_free_pkt(pkt);
>> +	}
>> +
>> +	spin_unlock_bh(&vvs->rx_lock);
>> +
>> +	virtio_transport_send_credit_update(vsk);
>> +
>> +	return dequeued_len;
>> +}
>> +
>> ssize_t
>> virtio_transport_stream_dequeue(struct vsock_sock *vsk,
>> 				struct msghdr *msg,
>> @@ -405,6 +477,18 @@ virtio_transport_stream_dequeue(struct vsock_sock *vsk,
>> }
>> EXPORT_SYMBOL_GPL(virtio_transport_stream_dequeue);
>>
>> +ssize_t
>> +virtio_transport_seqpacket_dequeue(struct vsock_sock *vsk,
>> +				   struct msghdr *msg,
>> +				   int flags)
>> +{
>> +	if (flags & MSG_PEEK)
>> +		return -EOPNOTSUPP;
>> +
>> +	return virtio_transport_seqpacket_do_dequeue(vsk, msg, flags);
>> +}
>> +EXPORT_SYMBOL_GPL(virtio_transport_seqpacket_dequeue);
>> +
>> int
>> virtio_transport_dgram_dequeue(struct vsock_sock *vsk,
>> 			       struct msghdr *msg,
>> -- 
>> 2.25.1
>>
>

  parent reply	other threads:[~2021-06-18 15:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11 11:07 [PATCH v11 00/18] virtio/vsock: introduce SOCK_SEQPACKET support Arseny Krasnov
2021-06-11 11:09 ` [PATCH v11 01/18] af_vsock: update functions for connectible socket Arseny Krasnov
2021-06-11 11:10 ` [PATCH v11 02/18] af_vsock: separate wait data loop Arseny Krasnov
2021-06-11 11:10 ` [PATCH v11 03/18] af_vsock: separate receive " Arseny Krasnov
2021-06-11 11:10 ` [PATCH v11 04/18] af_vsock: implement SEQPACKET receive loop Arseny Krasnov
2021-06-11 11:10 ` [PATCH v11 05/18] af_vsock: implement send logic for SEQPACKET Arseny Krasnov
2021-06-11 11:11 ` [PATCH v11 06/18] af_vsock: rest of SEQPACKET support Arseny Krasnov
2021-06-11 11:11 ` [PATCH v11 07/18] af_vsock: update comments for stream sockets Arseny Krasnov
2021-06-11 11:11 ` [PATCH v11 08/18] virtio/vsock: set packet's type in virtio_transport_send_pkt_info() Arseny Krasnov
2021-06-11 11:12 ` [PATCH v11 09/18] virtio/vsock: simplify credit update function API Arseny Krasnov
2021-06-11 11:12 ` [PATCH v11 10/18] virtio/vsock: defines and constants for SEQPACKET Arseny Krasnov
2021-06-11 11:12 ` [PATCH v11 11/18] virtio/vsock: dequeue callback for SOCK_SEQPACKET Arseny Krasnov
2021-06-18 13:44   ` Stefano Garzarella
2021-06-18 13:44     ` Stefano Garzarella
2021-06-18 13:51     ` Michael S. Tsirkin
2021-06-18 13:51       ` Michael S. Tsirkin
2021-06-18 14:44       ` Stefano Garzarella
2021-06-18 14:44         ` Stefano Garzarella
2021-06-18 15:04     ` Arseny Krasnov [this message]
2021-06-18 15:55       ` Stefano Garzarella
2021-06-18 15:55         ` Stefano Garzarella
2021-06-18 16:08         ` [MASSMAIL KLMS] " Arseny Krasnov
2021-06-18 16:25           ` Stefano Garzarella
2021-06-18 16:25             ` Stefano Garzarella
2021-06-18 16:26             ` Arseny Krasnov
2021-06-21  6:55               ` Arseny Krasnov
2021-06-21 10:23                 ` Stefano Garzarella
2021-06-21 10:23                   ` Stefano Garzarella
2021-06-21 12:27                   ` Arseny Krasnov
2021-06-11 11:12 ` [PATCH v11 12/18] virtio/vsock: add SEQPACKET receive logic Arseny Krasnov
2021-06-11 11:13 ` [PATCH v11 13/18] virtio/vsock: rest of SOCK_SEQPACKET support Arseny Krasnov
2021-06-11 11:13 ` [PATCH v11 14/18] virtio/vsock: enable SEQPACKET for transport Arseny Krasnov
2021-06-11 11:13 ` [PATCH v11 15/18] vhost/vsock: support " Arseny Krasnov
2021-06-11 11:13 ` [PATCH v11 16/18] vsock/loopback: enable " Arseny Krasnov
2021-06-11 11:14 ` [PATCH v11 17/18] vsock_test: add SOCK_SEQPACKET tests Arseny Krasnov
2021-06-11 11:14 ` [PATCH v11 18/18] virtio/vsock: update trace event for SEQPACKET Arseny Krasnov
2021-06-11 11:17 ` [PATCH v11 00/18] virtio/vsock: introduce SOCK_SEQPACKET support Arseny Krasnov
2021-06-11 12:25   ` Stefano Garzarella
2021-06-11 12:25     ` Stefano Garzarella
2021-06-11 14:39     ` Arseny Krasnov
2021-06-11 14:57       ` Stefano Garzarella
2021-06-11 14:57         ` Stefano Garzarella
2021-06-11 15:00         ` Arseny Krasnov
2021-06-11 21:00 ` patchwork-bot+netdevbpf
2021-06-18 13:49   ` Michael S. Tsirkin
2021-06-18 13:49     ` 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=bb323125-f802-1d16-7530-6e4f4abb00a6@kaspersky.com \
    --to=arseny.krasnov@kaspersky.com \
    --cc=andraprs@amazon.com \
    --cc=colin.king@canonical.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nslusarek@gmx.net \
    --cc=oxffffaa@gmail.com \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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.