Re: [virtio-comment] Re: [EXT] Re: [virtio-comment] Re: [PATCH] virtio-net: Add equal-sized receive buffers feature

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Dec 02, 2019 at 04:16:46PM +0000, Vitaly Mireyno wrote:
> >> >as an example of a vague idea, exposing max rx s/g, min buffer + max
> >> >buffer will allow device to force this from device side.
> >> >
> >> >Is that good? If not, how does driver decide on a good fixed buffer size?
> >> >
> >>
> >> Setting max=min=fixed_size by the device will work, but this seems too
> >restrictive, as we still may want to enable the driver to select its buffer size.
> >> I guess driver can select the fixed buffer size based on the MTU.
> >
> >
> >Would that be based on max MTU field then?
> >I note that that's read-only, so just starting with that and sending it back to the
> >device doesn't change much ...
> >
> 
> I had in mind the actual interface MTU, and not the maximum supported
> MTU (given the device provided one).  Perhaps it's a different
> discussion, but in this sense I find the 'mtu' field a bit confusing.
> Device advertises its maximum supported MTU, but then it's being used
> as an actual MTU (which can be much smaller).

This was sufficient for what it was used for (encapsulation).


> Shouldn't device enforce
> the actual MTU on TX and RX packets?

We need to think of a set of usecases to address though. It's also
tricky wrt things like migration.

>  I also noticed that the spec
> mentions the maximum RX packet size is strictly 1514 bytes (w/o TSO).

It might make sense to extend that for jumbo frames etc. And, I suspect
it doesn't match what drivers/devices actually do in all cases.
Would be great if someone looked at this some more.

> >> What if device will request max/min buffer size ratio, and driver will set min
> >buffer size? This can solve the fixed size issue, without forcing a specific size.
> >> Along with the max s/g, maybe it can also help avoiding rx buffer size abuse
> >by the driver (i.e. setting it too low).
> >
> >That sounds reasonably generic, too.
> >
> 
> Ok, I will formulate a new patch.
> 
> >--
> >MST
> 


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/