[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: [EXT] Re: [virtio-comment] Re: [PATCH] virtio-net: Add equal-sized receive buffers feature
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]