From: Cornelia Huck <cohuck@redhat.com>
To: Parav Pandit <parav@nvidia.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"mst@redhat.com" <mst@redhat.com>
Cc: Shahaf Shuler <shahafs@nvidia.com>,
"xuanzhuo@linux.alibaba.com" <xuanzhuo@linux.alibaba.com>,
"yuri.benditovich@daynix.com" <yuri.benditovich@daynix.com>
Subject: [virtio-comment] RE: [PATCH v2 1/2] virtio-net: Fix receive buffer size calculation text
Date: Tue, 16 Jan 2024 13:38:29 +0100 [thread overview]
Message-ID: <87le8pmp16.fsf@redhat.com> (raw)
In-Reply-To: <PH0PR12MB54815BB31B88DB812507A8A4DC732@PH0PR12MB5481.namprd12.prod.outlook.com>
On Tue, Jan 16 2024, Parav Pandit <parav@nvidia.com> wrote:
>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Tuesday, January 16, 2024 4:33 PM
>> To: Parav Pandit <parav@nvidia.com>; virtio-comment@lists.oasis-open.org;
>> mst@redhat.com
>> Cc: Shahaf Shuler <shahafs@nvidia.com>; xuanzhuo@linux.alibaba.com;
>> yuri.benditovich@daynix.com
>> Subject: RE: [PATCH v2 1/2] virtio-net: Fix receive buffer size calculation text
>>
>> On Tue, Jan 16 2024, Parav Pandit <parav@nvidia.com> wrote:
>>
>> >> From: Cornelia Huck <cohuck@redhat.com>
>> >> Sent: Monday, January 15, 2024 10:14 PM
>> >
>> >> On Mon, Jan 15 2024, Parav Pandit <parav@nvidia.com> wrote:
>> >> > +The driver MUST consider size of field \field{struct
>> >> > +virtio_net_hdr}
>> >> > +20 bytes if VIRTIO_NET_F_HASH_REPORT is negotiated, and 12 bytes
>> >> > +if
>> >> not.
>> >> > +
>> >>
>> >> Requiring the driver to consider the size of something to be its
>> >> actual size seems a bit odd :) I don't think we need this, as the
>> >> length can be derived from looking at the definitions, and is already
>> >> spelled out explicitly, if you consider my suggestion above.
>> > We need this because tx side also needs to refer to the virtio_net_hdr in
>> patch 2 to be same as that of the rx side.
>> > And hence, this normative sets base line for tx side too. Relying on rest of the
>> receive packet normative is not enough.
>>
>> Hm, why? If struct virtio_net_hdr is well-defined, its size is well-defined as
>> well, and we do not need to state it explictly?
> Because,
> the size of virtio_net_hdr is derived from the rx side features.
> Today there is no normative line that says that even though you are using A, B, C Rx features, due to which your tx side virtio_net_hdr also changes.
> The 2nd patch in this series adds this explicit normative as explained in the cover letter.
Let's step back a bit.
struct virtio_net_hdr is defined at the beginning of the "Device
Operation" section; the definition clearly says that the last three
fields depend on VIRTIO_NET_F_HASH_REPORT being negotiated. The device
and the driver agree on whether HASH_REPORT is negotiated, and therefore
should also agree on the size of virtio_net_hdr?
Or is the problem that we did not state explicitly that the last three
fields of virtio_net_hdr do not exist without HASH_REPORT (and are not
merely invalid)? If yes, we should spell this out, instead of adding
normative statements about what the size of virtio_net_hdr should be
considered to be. If virtio_net_hdr has a fixed size, we shouldn't need
the second patch, either.
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/
next prev parent reply other threads:[~2024-01-16 12:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 9:31 [virtio-comment] [PATCH v2 0/2] virtio-net: Clarify virtio_net_hdr size and rx buffer size Parav Pandit
2024-01-15 9:31 ` [virtio-comment] [PATCH v2 1/2] virtio-net: Fix receive buffer size calculation text Parav Pandit
2024-01-15 16:44 ` [virtio-comment] " Cornelia Huck
2024-01-16 3:45 ` [virtio-comment] " Parav Pandit
2024-01-16 11:02 ` Cornelia Huck
2024-01-16 11:23 ` Parav Pandit
2024-01-16 12:38 ` Cornelia Huck [this message]
2024-01-16 13:18 ` Parav Pandit
2024-01-16 13:29 ` [virtio-comment] " Michael S. Tsirkin
2024-01-19 12:25 ` [virtio-comment] " Parav Pandit
2024-02-01 5:57 ` Parav Pandit
2024-02-05 11:16 ` Parav Pandit
2024-02-05 15:19 ` [virtio-comment] " Cornelia Huck
2024-02-05 16:24 ` Parav Pandit
2024-02-06 17:02 ` Cornelia Huck
2024-02-06 17:57 ` Parav Pandit
2024-02-09 11:46 ` Parav Pandit
2024-01-15 9:31 ` [virtio-comment] [PATCH v2 2/2] virtio-net: Clarify the size of the struct virtio_net_hdr for tx Parav Pandit
2024-01-16 3:34 ` [virtio-comment] " Xuan Zhuo
2024-01-16 4:04 ` [virtio-comment] " Parav Pandit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87le8pmp16.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.com \
--cc=yuri.benditovich@daynix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox