From: Cornelia Huck <cohuck@redhat.com>
To: Heng Qi <hengqi@linux.alibaba.com>
Cc: Jason Wang <jasowang@redhat.com>,
xuanzhuo@linux.alibaba.com, kangjie.xu@linux.alibaba.com,
virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] Re: [PATCH] virtio_net: support split header
Date: Tue, 09 Aug 2022 17:33:56 +0200 [thread overview]
Message-ID: <87tu6lcty3.fsf@redhat.com> (raw)
In-Reply-To: <270139d6-1c00-9cd4-1ea9-b6f9769fedb8@linux.alibaba.com>
On Fri, Aug 05 2022, Heng Qi <hengqi@linux.alibaba.com> wrote:
> 在 2022/8/4 下午9:50, Cornelia Huck 写道:
>> On Thu, Aug 04 2022, Heng Qi<hengqi@linux.alibaba.com> wrote:
>>
>>> 在 2022/8/4 下午2:27, Jason Wang 写道:
>>>> On Mon, Aug 1, 2022 at 2:59 PM Heng Qi<hengqi@linux.alibaba.com> wrote:
>>>>> @@ -3820,9 +3826,13 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>>>>> driver MUST NOT use the \field{csum_start} and \field{csum_offset}.
>>>>>
>>>>> If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, UFO, USO4 or USO6 options have
>>>>> -been negotiated, the driver MAY use \field{hdr_len} only as a hint about the
>>>>> +been negotiated and the VIRTIO_NET_HDR_F_SPLIT_HEADER bit in \field{flags}
>>>>> +is not set, the driver MAY use \field{hdr_len} only as a hint about the
>>>>> transport header size.
>>>>> -The driver MUST NOT rely on \field{hdr_len} to be correct.
>>>>> +
>>>>> +If the VIRTIO_NET_HDR_F_SPLIT_HEADER bit in \field{flags} is not set, the driver
>>>>> +MUST NOT rely on \field{hdr_len} to be correct.
>>>> I think we should keep the above description as-is. For whatever case,
>>>> the driver must not trust the metadata set by the device and must
>>>> perform necessary sanity tests on them.
>>>
>>> My idea is to keep the current description as it is,
>>> but to emphasize in the next version:
>>> "If the VIRTIO_NET_HDR_F_SPLIT_HEADER bit in \field{flags} is set,
>>> the driver MAY treat the \field{hdr_len} as the length of the
>>> protocol header inside the first descriptor."
>>
>> Just to be clear, you suggest using
>>
>> "If one of the VIRTIO_NET_F_GUEST_TSO4, TSO6, UFO, USO4 or USO6 options have
>> been negotiated, the driver MAY use \field{hdr_len} only as a hint about the
>> transport header size.
>>
>> The driver MUST NOT rely on \field{hdr_len} to be correct.
>>
>> If the VIRTIO_NET_HDR_F_SPLIT_HEADER bit in \field{flags} is set,
>> the driver MAY treat the \field{hdr_len} as the length of the
>> protocol header inside the first descriptor."
>
> Yes. I will use the above description to make it clearer in the next version.
>
>
>>
>> (Maybe "...the driver MAY use \field{hdr_len} as a hint about the length
>> of the protocol header..."? It's still not reliable, right?)
>>
> \field{hdr_len} is unreliable when VIRTIO_NET_F_SPLIT_HEADER is not negotiated.
>
>
> If VIRTIO_NET_F_SPLIT_HEADER is negotiated, "split header" MAY perform the split
> from the IP layer, so the protocol header and the transport header are different.
>
> so I think the "...the driver MAY use \field{hdr_len} only as a hint about the
> transport header size..." paragraph can be left as-is.
Ok, then let's keep it like that.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2022-08-09 15:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-01 6:59 [virtio-dev] [PATCH] virtio_net: support split header Heng Qi
2022-08-01 8:28 ` [virtio-dev] " Heng Qi
2022-08-04 6:27 ` Jason Wang
2022-08-04 13:01 ` Heng Qi
2022-08-04 13:50 ` Cornelia Huck
2022-08-05 5:59 ` Heng Qi
2022-08-09 15:33 ` Cornelia Huck [this message]
2022-08-11 9:01 ` Xuan Zhuo
[not found] ` <4ea77b4a-2571-2b12-433c-2f1a8ceaeff8@linux.alibaba.com>
[not found] ` <CACGkMEvTr44xhziEwMhCpAVp4dWDPvGHfkwGm+o4WRqsKBX=gw@mail.gmail.com>
2022-08-10 9:10 ` Heng Qi
-- strict thread matches above, loose matches on Subject: below --
2022-02-16 3:01 [virtio-dev] " Xuan Zhuo
2022-02-16 4:32 ` [virtio-dev] " Jason Wang
2022-02-16 6:05 ` Xuan Zhuo
2022-02-17 7:01 ` Jason Wang
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=87tu6lcty3.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=kangjie.xu@linux.alibaba.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.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