RE: [virtio-dev] RE: RE: RE: RE: [PATCH v16] virtio-net: support device stats

[Parav Pandit <parav@nvidia.com>]

> From: Heng Qi <hengqi@linux.alibaba.com>
> Sent: Monday, September 4, 2023 4:41 PM
> 
> å 2023/9/4 äå6:26, Parav Pandit åé:
> >> From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >> Sent: Monday, September 4, 2023 2:23 PM
> >
> >>> "The device MUST NOT pass received packets that exceed mtu (plus low
> >>> level ethernet header length) size with gso_type NONE or ECN after
> >> VIRTIO_NET_F_MTU has been successfully negotiated."
> >>
> >> NO.
> >>
> >> If the mtu is 1500, we can pass 64k packets to the driver with
> >> gso_type (not NONE).
> > Any supporting citation to spec for above comment?
> 
> I think it can be referred here:
> "The converse features are also available: a driver can save the virtual device
> some work by negotiating these features. Note: For example, a network packet
> transported between two guests on the same system might not need
> checksumming at all, nor segmentation, if both guests are amenable."
> 
Sure, it can avoid segmentation, but not at the cost of skipping mtu check.
For example, sender sends skb with gso with each segment of 9K, and receiver has mtu of 1500, same skb without segmentation is not good.
Because gso_size should be same as 1500 to match the mtu.
One can say with violation of line " The device MUST NOT pass received packets..." things still work fine because guest is amenable. :)

So counter looks ok to me when VIRTIO_NET_F_MTU is not negotiated or when mtu matches.

> >
> > Each packet must be 1500 for the mtu normative above.
> > gso_size to <= mtu (ingoring the hdr math for simplicity for now).
> > whole GSO completion can be for 64K to be reported in used_elem.len.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org