On Fri, Jun 30, 2023 at 09:55:41AM +0800, Heng Qi wrote:
>
>
> 在 2023/6/30 上午9:36, Parav Pandit 写道:
> >
> > > From: Heng Qi <hen...@linux.alibaba.com>
> > > Sent: Thursday, June 29, 2023 8:54 PM
> > >
> > > On Thu, Jun 29, 2023 at 04:59:28PM +0000, Parav Pandit wrote:
> > > >
> > > > > From: Michael S. Tsirkin <m...@redhat.com>
> > > > > Sent: Thursday, June 29, 2023 7:48 AM
> > > >
> > > > > > > struct virtio_net_hash_config reserved is fine.
> > > > > > +1.
> > > > > >
> > > > > > Inner header hash is orthogonal to RSS, and it's fine to have its
> > > > > > own structure and commands.
> > > > > > There is no need to send additional RSS fields when we configure
> > > > > > inner header hash.
> > > > > >
> > > > > > Thanks.
> > > > > Not RSS, hash calculations. It's not critical, but I note that
> > > > > practically you said you will enable this with symmetric hash so it
> > > > > makes sense to me to send this in the same command with the key.
> > > > >
> > > > In the v19, we have,
> > > >
> > > > +\item[VIRTIO_NET_F_HASH_TUNNEL] Requires VIRTIO_NET_F_CTRL_VQ
> > > along with VIRTIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT.
> > > > So it is done along with rss, so in same struct as rss config is fine.
> > > Do you mean having both virtio_net_rss_config and virtio_net_hash_config
> > > have enabled_hash_types?
> > > Like this:
> > >
> > > struct virtio_net_rss_config {
> > > le32 hash_types;
> > > le16 indirection_table_mask;
> > > struct rss_rq_id unclassified_queue;
> > > struct rss_rq_id indirection_table[indirection_table_length];
> > > le16 max_tx_vq;
> > > u8 hash_key_length;
> > > u8 hash_key_data[hash_key_length];
> > > + le32 enabled_tunnel_types;
> > > };
> > >
> > > struct virtio_net_hash_config {
> > > le32 hash_types;
> > > - le16 reserved[4];
> > > + le32 enabled_tunnel_types;
> > > + le16 reserved[2];
> > > u8 hash_key_length;
> > > u8 hash_key_data[hash_key_length];
> > > };
Oh, I forgot that rss and hash had identical structures.
And we want to keep that I think.
But now it's not clear to me: does the same enabled_tunnel_types
apply to both hash calculation and rss?
I note we normally have separate configs for hash and rss.
So to keep it consistent what should we do? two set commands?
Or does enabled_tunnel_types apply to both rss and hash?
We should have reserved more space. We can still do it if you like:
struct virtio_net_rss_tunnel_config {
le32 enabled_tunnel_types;
le16 reserved[6];
struct virtio_net_rss_config hash;
};
struct virtio_net_hash_tunnel_config {
le32 enabled_tunnel_types;
le16 reserved[6];
struct virtio_net_hash_config hash;
};
?
> > >
> > >
> > > If yes, this should have been discussed in v10 [1] before,
> > > enabled_tunnel_types
> > > in virtio_net_rss_config will follow the variable length field and cause
> > > misalignment.
> > >
> > > If we let the inner header hash reuse the virtio_net_hash_config
> > > structure, it
> > > can work, but the only disadvantage is that the configuration of the inner
> > > header hash and *RSS*(not hash calculations) becomes somewhat coupled.
> > > Just imagine:
> > > If the driver and the device negotiated VIRTIO_NET_F_HASH_TUNNEL and
> > > VIRTIO_NET_F_RSS, but did not negotiate VIRTIO_NET_F_HASH_REPORT, 1.
> > > then if we only want to configure the inner header hash (such as
> > > enabled_tunnel_types), it is good for us to send virtio_net_hash_config
> > > alone;
> > > 2. but then if we want to configure the inner header hash and RSS (such as
> > > indirection table), we need to send all virtio_net_rss_config and
> > > virtio_net_hash_config once, because virtio_net_rss_config now does not
> > > carry
> > > enabled_tunnel_types due to misalignment.
> > >
> > > So, I think the following structure will make it clearer to configure
> > > inner header
> > > hash and RSS/hash calculation.
> > > But in any case, if we still propose to reuse virtio_net_hash_config
> > > proposal, I
> > > am ok, no objection:
> > >
> > > 1. The supported_tunnel_types are placed in the device config space;
> > >
> > Yes. I forgot the variable length part.
> > The second disadvantage I remember now is one need to resupply all the rss
> > hash config parameter and device needs to compare and modify for this one
> > field.
Or it could be an advantage since one normally wants to configure a
symmetric key with this. Further device can just use the new config
with no need to check what the old one was. I'd call it a wash.
> > Given these two disadvantages, I also prefer independent SET command the
> > way you have it.
>
> OK, let's wait for Michael's input again.
>
> Thanks.
This part is not critical to me, but now I understand we need two sets of SET
commands.
> > > 2.
> > > Reserve the following structure:
> > >
> > > struct virtnet_hash_tunnel {
> > > le32 enabled_tunnel_types;
> > > };
> > >
> > > 3. Reserve the SET command for enabled_tunnel_types and remove the GET
> > > command for enabled_tunnel_types.
> > >
> > > [1] https://lists.oasis-open.org/archives/virtio-dev/202303/msg00317.html
> > >
> > > Thanks a lot!
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
