From: Heng Qi <hengqi@linux.alibaba.com>
To: Cornelia Huck <cohuck@redhat.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: Fri, 5 Aug 2022 13:59:18 +0800 [thread overview]
Message-ID: <270139d6-1c00-9cd4-1ea9-b6f9769fedb8@linux.alibaba.com> (raw)
In-Reply-To: <87bkt086ef.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]
在 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.
[-- Attachment #2: Type: text/html, Size: 3559 bytes --]
next prev parent reply other threads:[~2022-08-05 5:59 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 [this message]
2022-08-09 15:33 ` Cornelia Huck
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=270139d6-1c00-9cd4-1ea9-b6f9769fedb8@linux.alibaba.com \
--to=hengqi@linux.alibaba.com \
--cc=cohuck@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.