Re: [PATCH 1/1] virtio/vsock: Make vsock virtio packet buff size configurable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 09, 2022 at 07:48:02PM +0000, Carlos Llamas wrote:
On Thu, Jul 22, 2021 at 02:55:19PM +0200, Stefano Garzarella wrote:
>
> +uint virtio_transport_max_vsock_pkt_buf_size = 1024 * 64;
> +module_param(virtio_transport_max_vsock_pkt_buf_size, uint, 0444);
> +EXPORT_SYMBOL_GPL(virtio_transport_max_vsock_pkt_buf_size);
> +

I'm interested on this functionality, so I could take this on.

Great!
We are changing the packet handling using sk_buff [1], so I think it's better to rebase on that work that should be merged in net-next after the current merge window will close.



Maybe better to add an entry under sysfs similar to what Jiang proposed
here:
https://lists.linuxfoundation.org/pipermail/virtualization/2021-June/054769.html

Having a look at Jiang's RFC patch it seems the proposed sysfs node
hangs off from the main kernel object e.g. /sys/kernel. So I wonder if
there is a more appropriate parent for this knob?

Agree, what about /sys/devices ?
I would take a closer look at what is recommend in this case.


Also, I noticed that Ram's patch here is using read-only permissions for
the module parameter and switching to sysfs would mean opening this knob
up to be dynamically configured? I'd need to be careful here.


True, but even if it's changed while we're running, I don't think it's a big problem.

Maybe the problem here would be the allocation of RX buffers made during the probe. Could this be a good reason to use a module parameter?

Thanks,
Stefano

[1] https://lore.kernel.org/lkml/20221202173520.10428-1-bobby.eshleman@xxxxxxxxxxxxx/




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux