From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
Jason Wang <jasowang@redhat.com>,
Yuri Benditovich <yuri.benditovich@daynix.com>,
Cornelia Huck <cohuck@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: Re: [PATCH v9] virtio-net: support inner header hash
Date: Tue, 21 Feb 2023 18:18:01 -0500 [thread overview]
Message-ID: <20230221180945-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB54816DA52C42EE769C4CBAF4DCA59@PH0PR12MB5481.namprd12.prod.outlook.com>
On Tue, Feb 21, 2023 at 10:32:11PM +0000, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, February 21, 2023 4:46 PM
> >
> > What is this information driver can't observe? It sees all the packets after all,
> > we are not stripping tunneling headers.
> Just the tunnel type.
> If/when that tunnel header is stripped, it gets complicated where tunnel type is still present in the virtio_net_hdr because hash_report_tunnel feature bit is negotiated.
whoever strips off the tunnel has I imagine strip off the virtio net hdr
too - everything else in it such as gso type refers to the outer packet.
> > I also don't really know what are upper layer drivers - for sure layering of
> > drivers is not covered in the spec for now so I am not sure what do you mean by
> > that. The risk I mentioned is leaking the information *on the network*.
> >
> Got it.
>
> >
> >
> >
> > > > > > \begin{lstlisting} struct virtio_net_rss_config {
> > > > > > > > le32 hash_types;
> > > > > > > > + le32 hash_tunnel_types;
> > > > > > > This field is not needed as device config space advertisement
> > > > > > > for the support
> > > > > > is enough.
> > > > > > >
> > > > > > > If the intent is to enable hashing for the specific tunnel(s),
> > > > > > > an individual
> > > > > > command is better.
> > > > > >
> > > > > > new command? I am not sure why we want that. why not handle
> > > > > > tunnels like we do other protocols?
> > > > >
> > > > > I didn't follow.
> > > > > We probably discussed in another thread that to set M bits, it is
> > > > > wise to avoid
> > > > setting N other bits just to keep the command happy, where N >>> M
> > > > and these N have a very strong relation in hw resource setup and packet
> > steering.
> > > > > Any examples of 'other protocols'?
> > > >
> > > > #define VIRTIO_NET_HASH_TYPE_IPv4 (1 << 0)
> > > > #define VIRTIO_NET_HASH_TYPE_TCPv4 (1 << 1)
> > > > #define VIRTIO_NET_HASH_TYPE_UDPv4 (1 << 2)
> > > >
> > > > this kind of thing.
> > > >
> > > > I don't see how a tunnel is different fundamentally. Why does it
> > > > need its own field?
> > >
> > > Driver is in control to enable/disable tunnel based inner hash acceleration
> > only when its needed.
> > > This way certain data path hw parsers can be enabled/disabled.
> > > Without this it will be always enabled even if there may not be any user of it.
> > > Device has scope to optimize this flow.
> >
> > I feel you misunderstand the question. Or maybe I misunderstand what you are
> > proposing. So tunnels need their own bits. But why a separate field and not just
> > more bits along the existing ones?
>
> Because the hashing is not covering the outer header contents.
>
> We may be still not discussing the same.
> So let me refresh the context.
>
> The question of discussion was,
> Scenario:
> 1. device advertises the ability to hash on the inner packet header.
> 2. device prefers that driver enable it only when it needs to use this extra packet parser in hardware.
>
> There are 3 options.
> a. Because the feature is negotiated, it means it is enabled for all the tunnel types.
> Pros:
> 1. No need to extend cvq cmd.
> Cons:
> 1. device parser is always enabled, and the driver never uses it. This may result in inferior rx performance.
>
> b. Since the feature is useful in a narrow case of sw-based vxlan etc driver, better not to enable hw for it.
> Hence, have the knob to explicitly enable in hw.
> So have the cvq command.
> b.1 should it be combined with the existing command?
> Cons:
> a. when the driver wants to enable hash on inner, it needs to supply the exact same RSS config as before. Sw overhead with no gain.
> b. device needs to parse new command value, compare with old config, and drop the RSS config, just enable inner hashing hw parser.
> Or destroy the old rss config and re-apply. This results in weird behavior for the short interval with no apparent gain.
>
> b.2 should it be on its own command?
> Pros:
> a. device and driver doesn't need to bother about b.1.a and b.1.b.
> b. still benefits from not always enabling hw parser, as this is not a common case.
> c. has the ability to enable when needed.
I prefer b.1. With reporting of the tunnel type gone I don't see a
fundamental difference between hashing over tunneling types and other
protocol types we support. It's just a flag telling device over which
bits to calculate the hash. We don't have a separate command for hashing
of TCPv6, why have it for vxlan? Extending with more HASH_TYPE makes
total sense to me, seems to fit better with the existing design and will
make patch smaller.
--
MST
next prev parent reply other threads:[~2023-02-21 23:18 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-18 14:37 [PATCH v9] virtio-net: support inner header hash Heng Qi
2023-02-20 15:53 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2023-02-20 16:12 ` Michael S. Tsirkin
2023-02-21 4:20 ` Parav Pandit
2023-02-21 6:14 ` [virtio-comment] " Heng Qi
2023-02-21 12:47 ` Parav Pandit
2023-02-21 13:34 ` Heng Qi
2023-02-21 15:32 ` Parav Pandit
2023-02-21 16:44 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2023-02-21 16:50 ` Parav Pandit
2023-02-21 17:13 ` Michael S. Tsirkin
2023-02-21 17:40 ` [virtio-comment] " Parav Pandit
2023-02-21 17:44 ` Michael S. Tsirkin
2023-02-21 17:54 ` Parav Pandit
2023-02-21 17:17 ` [virtio-comment] " Heng Qi
2023-02-21 17:39 ` Parav Pandit
2023-02-21 13:37 ` Heng Qi
2023-02-21 17:05 ` Michael S. Tsirkin
2023-02-21 19:29 ` Parav Pandit
2023-02-21 21:23 ` Michael S. Tsirkin
2023-02-21 21:36 ` Parav Pandit
2023-02-21 21:46 ` Michael S. Tsirkin
2023-02-21 22:32 ` Parav Pandit
2023-02-21 23:18 ` Michael S. Tsirkin [this message]
2023-02-22 1:41 ` Parav Pandit
2023-02-22 2:51 ` [virtio-dev] " Heng Qi
2023-02-22 2:34 ` [virtio-dev] " Heng Qi
2023-02-22 6:21 ` Michael S. Tsirkin
2023-02-22 7:03 ` Heng Qi
2023-02-22 11:29 ` Michael S. Tsirkin
2023-03-01 14:32 ` [virtio-dev] " Heng Qi
2023-02-21 17:50 ` Michael S. Tsirkin
2023-02-22 3:22 ` Jason Wang
2023-02-22 6:46 ` Heng Qi
2023-02-22 11:30 ` Michael S. Tsirkin
2023-02-23 2:50 ` Jason Wang
2023-02-23 4:41 ` [virtio-dev] " Heng Qi
2023-02-24 2:45 ` Jason Wang
2023-02-24 4:47 ` [virtio-comment] " Heng Qi
2023-02-24 8:07 ` Michael S. Tsirkin
2023-02-23 13:03 ` Michael S. Tsirkin
2023-02-24 2:26 ` Jason Wang
2023-02-24 8:06 ` [virtio-dev] " Michael S. Tsirkin
2023-02-27 4:07 ` Jason Wang
2023-02-27 4:07 ` [virtio-dev] " Jason Wang
2023-02-27 7:39 ` Michael S. Tsirkin
2023-02-27 7:39 ` [virtio-dev] " Michael S. Tsirkin
2023-02-27 8:35 ` Jason Wang
2023-02-27 8:35 ` [virtio-dev] " Jason Wang
2023-02-27 12:38 ` Heng Qi
2023-02-27 12:38 ` [virtio-dev] " Heng Qi
2023-02-27 17:49 ` Michael S. Tsirkin
2023-02-27 17:49 ` [virtio-dev] " Michael S. Tsirkin
2023-02-28 3:04 ` Jason Wang
2023-02-28 3:04 ` [virtio-dev] " Jason Wang
2023-02-28 8:52 ` Michael S. Tsirkin
2023-02-28 8:52 ` [virtio-dev] " Michael S. Tsirkin
2023-02-28 9:56 ` Heng Qi
2023-02-28 9:56 ` Heng Qi
2023-02-28 11:04 ` Michael S. Tsirkin
2023-02-28 11:04 ` [virtio-dev] " Michael S. Tsirkin
2023-03-01 2:36 ` Jason Wang
2023-03-01 2:36 ` [virtio-dev] " Jason Wang
2023-03-01 10:36 ` Michael S. Tsirkin
2023-03-02 2:57 ` Jason Wang
2023-03-02 7:42 ` Michael S. Tsirkin
2023-03-02 7:57 ` Jason Wang
2023-03-02 8:09 ` Michael S. Tsirkin
2023-03-02 8:15 ` Jason Wang
2023-03-02 8:41 ` Michael S. Tsirkin
2023-03-02 8:59 ` Jason Wang
2023-03-02 9:46 ` Michael S. Tsirkin
2023-02-23 13:13 ` Michael S. Tsirkin
2023-02-23 14:40 ` [virtio-comment] " Parav Pandit
2023-02-24 8:13 ` Michael S. Tsirkin
2023-02-24 14:38 ` [virtio-dev] " Heng Qi
2023-02-24 17:10 ` Michael S. Tsirkin
2023-02-24 17:10 ` Michael S. Tsirkin
2023-02-27 0:29 ` Parav Pandit
2023-02-27 0:29 ` [virtio-dev] " Parav Pandit
2023-02-24 4:42 ` Heng Qi
2023-02-24 8:04 ` Michael S. Tsirkin
2023-02-28 11:16 ` Michael S. Tsirkin
2023-02-28 11:16 ` [virtio-dev] " Michael S. Tsirkin
2023-03-01 2:56 ` Heng Qi
2023-03-01 2:56 ` Heng Qi
2023-03-08 14:39 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-03-09 4:55 ` Heng Qi
2023-03-09 19:36 ` Michael S. Tsirkin
2023-03-11 3:23 ` Heng Qi
2023-03-15 11:58 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-03-15 12:55 ` Heng Qi
2023-03-15 14:57 ` Michael S. Tsirkin
2023-03-16 13:17 ` Heng Qi
2023-03-20 19:45 ` Michael S. Tsirkin
2023-03-30 12:10 ` Heng Qi
2023-03-20 19:48 ` Michael S. Tsirkin
2023-03-30 12:37 ` Heng Qi
2023-04-08 10:29 ` Michael S. Tsirkin
2023-04-10 13:26 ` Heng Qi
2023-03-01 3:30 ` [virtio-comment] " Heng Qi
2023-03-01 3:30 ` [virtio-dev] " Heng Qi
2023-03-01 11:07 ` Michael S. Tsirkin
2023-03-01 15:10 ` Heng Qi
2023-03-09 12:28 ` [virtio-dev] " Heng Qi
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=20230221180945-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@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;
as well as URLs for NNTP newsgroup(s).