lkml.org 
[lkml]   [2019]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 1/8] vsock/virtio: limit the memory used per-socket
    From
    Date

    On 2019/5/29 上午12:45, Stefano Garzarella wrote:
    > On Wed, May 15, 2019 at 10:48:44AM +0800, Jason Wang wrote:
    >> On 2019/5/15 上午12:35, Stefano Garzarella wrote:
    >>> On Tue, May 14, 2019 at 11:25:34AM +0800, Jason Wang wrote:
    >>>> On 2019/5/14 上午1:23, Stefano Garzarella wrote:
    >>>>> On Mon, May 13, 2019 at 05:58:53PM +0800, Jason Wang wrote:
    >>>>>> On 2019/5/10 下午8:58, Stefano Garzarella wrote:
    >>>>>>> +static struct virtio_vsock_buf *
    >>>>>>> +virtio_transport_alloc_buf(struct virtio_vsock_pkt *pkt, bool zero_copy)
    >>>>>>> +{
    >>>>>>> + struct virtio_vsock_buf *buf;
    >>>>>>> +
    >>>>>>> + if (pkt->len == 0)
    >>>>>>> + return NULL;
    >>>>>>> +
    >>>>>>> + buf = kzalloc(sizeof(*buf), GFP_KERNEL);
    >>>>>>> + if (!buf)
    >>>>>>> + return NULL;
    >>>>>>> +
    >>>>>>> + /* If the buffer in the virtio_vsock_pkt is full, we can move it to
    >>>>>>> + * the new virtio_vsock_buf avoiding the copy, because we are sure that
    >>>>>>> + * we are not use more memory than that counted by the credit mechanism.
    >>>>>>> + */
    >>>>>>> + if (zero_copy && pkt->len == pkt->buf_len) {
    >>>>>>> + buf->addr = pkt->buf;
    >>>>>>> + pkt->buf = NULL;
    >>>>>>> + } else {
    >>>>>> Is the copy still needed if we're just few bytes less? We meet similar issue
    >>>>>> for virito-net, and virtio-net solve this by always copy first 128bytes for
    >>>>>> big packets.
    >>>>>>
    >>>>>> See receive_big()
    >>>>> I'm seeing, It is more sophisticated.
    >>>>> IIUC, virtio-net allocates a sk_buff with 128 bytes of buffer, then copies the
    >>>>> first 128 bytes, then adds the buffer used to receive the packet as a frag to
    >>>>> the skb.
    >>>> Yes and the point is if the packet is smaller than 128 bytes the pages will
    >>>> be recycled.
    >>>>
    >>>>
    >>> So it's avoid the overhead of allocation of a large buffer. I got it.
    >>>
    >>> Just a curiosity, why the threshold is 128 bytes?
    >>
    >> From its name (GOOD_COPY_LEN), I think it just a value that won't lose much
    >> performance, e.g the size two cachelines.
    >>
    > Jason, Stefan,
    > since I'm removing the patches to increase the buffers to 64 KiB and I'm
    > adding a threshold for small packets, I would simplify this patch,
    > removing the new buffer allocation and copying small packets into the
    > buffers already queued (if there is a space).
    > In this way, I should solve the issue of 1 byte packets.
    >
    > Do you think could be better?


    I think so.

    Thanks


    >
    > Thanks,
    > Stefano

    \
     
     \ /
      Last update: 2019-05-29 03:00    [W:2.248 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site