Re: [virtio-dev] Re: [virtio-comment] Re: [PATCH v9] virtio-net: support inner header hash
在 2023/3/1 下午7:07, Michael S. Tsirkin 写道: On Wed, Mar 01, 2023 at 11:30:37AM +0800, Heng Qi wrote: 在 2023/2/28 下午7:16, Michael S. Tsirkin 写道: On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote: If the tunnel is used to encapsulate the packets, the hash calculated using the outer header of the receive packets is always fixed for the same flow packets, i.e. they will be steered to the same receive queue. Wait a second. How is this true? Does not everyone stick the inner header hash in the outer source port to solve this? For example geneve spec says: it is necessary for entropy from encapsulated packets to be exposed in the tunnel header. The most common technique for this is to use the UDP source port same goes for vxlan did not check further. so what is the problem? and which tunnel types actually suffer from the problem? In fact, similar to protocols such as GRE, there is no outer transport header. Thanks. Sorry I don't understand the answer. What is similar to what? By GRE you mean NVGRE? That has FlowID for this purpose. Only 8 bit - is this the issue? Not enough entropy? Sorry I almost missed this email. Did you miss the reply in the other thread: " The end point of the tunnel called the gateway (with DPDK on top of it). 1. When there is no inner header hash, entropy can be inserted into the udp src port of the outer header of the tunnel, and then the tunnel packet is handed over to the host. The host needs to take out a part of the CPUs to parse the outer headers (but not drop them) to calculate the inner hash for the inner payloads, and then use the inner hash to forward them to another part of the CPUs that are responsible for processing. 1). During this process, the CPUs on the host are divided into two parts, one part is used as a forwarding node to parse the outer header, and the CPU utilization is low. Another part handles packets. 2). The entropy of the source udp src port is not enough, that is, the queue is not widely distributed. 2. When there is an inner header hash, the gateway will directly help parse the outer header, and use the inner 5 tuples to calculate the inner hash. The tunneled packet is then handed over to the host. 1) All the CPUs of the host are used to process data packets, and there is no need to use some CPUs to forward and parse the outer header. 2) The entropy of the original quintuple is sufficient, and the queue is widely distributed. " In this thread, I mean protocols such as Generic Routing Encapsulation (GRE)[1], which have IPv4 as *Delivery Header*. Compared with VXLAN, which increases entropy through outer udp src port, GRE has less entropy. [1] https://www.rfc-editor.org/rfc/rfc2784.html Thanks. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] Re: [PATCH v9] virtio-net: support inner header hash
On Wed, Mar 01, 2023 at 11:30:37AM +0800, Heng Qi wrote: > > > 在 2023/2/28 下午7:16, Michael S. Tsirkin 写道: > > On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote: > > > If the tunnel is used to encapsulate the packets, the hash calculated > > > using the outer header of the receive packets is always fixed for the > > > same flow packets, i.e. they will be steered to the same receive queue. > > Wait a second. How is this true? Does not everyone stick the > > inner header hash in the outer source port to solve this? > > For example geneve spec says: > > > > it is necessary for entropy from encapsulated packets to be > > exposed in the tunnel header. The most common technique for this is > > to use the UDP source port > > > > same goes for vxlan did not check further. > > > > so what is the problem? and which tunnel types actually suffer from the > > problem? > > > In fact, similar to protocols such as GRE, there is no outer transport > header. > > Thanks. Sorry I don't understand the answer. What is similar to what? By GRE you mean NVGRE? That has FlowID for this purpose. Only 8 bit - is this the issue? Not enough entropy? -- MST - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] Re: [PATCH v9] virtio-net: support inner header hash
在 2023/2/28 下午7:16, Michael S. Tsirkin 写道: On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote: If the tunnel is used to encapsulate the packets, the hash calculated using the outer header of the receive packets is always fixed for the same flow packets, i.e. they will be steered to the same receive queue. Wait a second. How is this true? Does not everyone stick the inner header hash in the outer source port to solve this? For example geneve spec says: it is necessary for entropy from encapsulated packets to be exposed in the tunnel header. The most common technique for this is to use the UDP source port same goes for vxlan did not check further. so what is the problem? and which tunnel types actually suffer from the problem? In fact, similar to protocols such as GRE, there is no outer transport header. Thanks. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
RE: [virtio-dev] RE: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
> From: Michael S. Tsirkin > Sent: Tuesday, February 21, 2023 12:44 PM > > On Tue, Feb 21, 2023 at 05:40:51PM +, Parav Pandit wrote: > > > > > From: Michael S. Tsirkin > > > Sent: Tuesday, February 21, 2023 12:14 PM > > > > The part that I am missing is, how do to reuse > > > > virtio_net_hash_config and say > > > ignore all the existing fields related to rss, but only consider > > > hash_tunnel_types? > > > > > > Like a union? The answer is, don't. Just lay out fields one after > > > another. > > > > > In that case driver needs to fill up all the fields which are not > > related to hash_tunnel_types and the device also needs to compare with > > the previous config and ignore it. Doesn’t look like a good use of > > existing commands and sw/fw usage for it. Shouldn’t we have the > > explicit command for setting tunnel types? > > I don't know what's proposed at this point, this is too vague. Proposal is to have new command like how Heng drafted in latest email. > I feel which tunnels to hash for inner header is not different from which > transports to hash. If device wants to know what changes it can compare. I > expect generally devices will just apply the new config without caring what > changed exactly. In a device when things are programmed, it often requires removing the previous configuration and re-apply the new one. This results in wrong steering for several tens of micro to milli seconds for no apparent reason. Hence, comparison is often needed for the best experience. And those are just overheads on the device and driver side without any apparent gain other than reusing some structure of rss. Hence, a separate command is more efficient choice.
Re: [virtio-dev] RE: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
On Tue, Feb 21, 2023 at 05:40:51PM +, Parav Pandit wrote: > > > From: Michael S. Tsirkin > > Sent: Tuesday, February 21, 2023 12:14 PM > > > The part that I am missing is, how do to reuse virtio_net_hash_config and > > > say > > ignore all the existing fields related to rss, but only consider > > hash_tunnel_types? > > > > Like a union? The answer is, don't. Just lay out fields one after another. > > > In that case driver needs to fill up all the fields which are not > related to hash_tunnel_types and the device also needs to compare with > the previous config and ignore it. Doesn’t look like a good use of > existing commands and sw/fw usage for it. Shouldn’t we have the > explicit command for setting tunnel types? I don't know what's proposed at this point, this is too vague. I feel which tunnels to hash for inner header is not different from which transports to hash. If device wants to know what changes it can compare. I expect generally devices will just apply the new config without caring what changed exactly. -- MST - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
RE: [virtio-dev] RE: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
> From: Michael S. Tsirkin > Sent: Tuesday, February 21, 2023 12:14 PM > > The part that I am missing is, how do to reuse virtio_net_hash_config and > > say > ignore all the existing fields related to rss, but only consider > hash_tunnel_types? > > Like a union? The answer is, don't. Just lay out fields one after another. > In that case driver needs to fill up all the fields which are not related to hash_tunnel_types and the device also needs to compare with the previous config and ignore it. Doesn’t look like a good use of existing commands and sw/fw usage for it. Shouldn’t we have the explicit command for setting tunnel types?
[virtio-dev] RE: [virtio-comment] RE: [virtio-dev] RE: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
> From: Heng Qi
> Sent: Tuesday, February 21, 2023 12:17 PM
>
> 在 2023/2/22 上午12:50, Parav Pandit 写道:
> >> From: Heng Qi
> >> Sent: Tuesday, February 21, 2023 11:44 AM
> >>> Patch-1 to introduce the feature bit, description, and link to CVQ
> dependency.
> >>> Patch-2 for its link in virtio_net_config structure and description.
> >>> Patch-3 for new command touching control VQ pieces.
> >> Yes, and you seem to have missed my other replies in this thread:), I
> >> rephrased
> > Was it comment "And virtio_net_hash_config seems to suffice except for le16
> reserved[4]." ?
> > I don’t see these reserved fields in the current structure.
> >
> >> it here:
> >> virtio_net_hash_config seems to be reusable, as the v9 patch is
> >> doing, why don't we re-use it?
> >> The reason I can think of is to not expand the virtio_net_hash_config
> >> structure, just set a separate structure for VIRTIO_NET_F_HASH_TUNNEL
> >> and include hash_tunnel_types?
> > The part that I am missing is, how do to reuse virtio_net_hash_config and
> > say
> ignore all the existing fields related to rss, but only consider
> hash_tunnel_types?
>
> Are you referring to such a command?
>
> #define VIRTIO_NET_CTRL_HASH_TUNNEL_TYPE 1 struct
> virtio_net_tunnel_type_config {
> le32 hash_tunnel_types;
> };
>
> Thanks.
Yes.
Re: [virtio-dev] RE: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
On Tue, Feb 21, 2023 at 04:50:56PM +, Parav Pandit wrote: > > > From: Heng Qi > > Sent: Tuesday, February 21, 2023 11:44 AM > > > > Patch-1 to introduce the feature bit, description, and link to CVQ > > > dependency. > > > Patch-2 for its link in virtio_net_config structure and description. > > > Patch-3 for new command touching control VQ pieces. > > > > Yes, and you seem to have missed my other replies in this thread:), I > > rephrased > Was it comment "And virtio_net_hash_config seems to suffice except for le16 > reserved[4]." ? > I don’t see these reserved fields in the current structure. > > > it here: > > virtio_net_hash_config seems to be reusable, as the v9 patch is doing, why > > don't we re-use it? > > The reason I can think of is to not expand the virtio_net_hash_config > > structure, > > just set a separate structure for VIRTIO_NET_F_HASH_TUNNEL and include > > hash_tunnel_types? > > The part that I am missing is, how do to reuse virtio_net_hash_config and say > ignore all the existing fields related to rss, but only consider > hash_tunnel_types? Like a union? The answer is, don't. Just lay out fields one after another. -- MST - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
RE: [virtio-dev] RE: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
> From: Heng Qi > Sent: Tuesday, February 21, 2023 11:44 AM > > Patch-1 to introduce the feature bit, description, and link to CVQ > > dependency. > > Patch-2 for its link in virtio_net_config structure and description. > > Patch-3 for new command touching control VQ pieces. > > Yes, and you seem to have missed my other replies in this thread:), I > rephrased Was it comment "And virtio_net_hash_config seems to suffice except for le16 reserved[4]." ? I don’t see these reserved fields in the current structure. > it here: > virtio_net_hash_config seems to be reusable, as the v9 patch is doing, why > don't we re-use it? > The reason I can think of is to not expand the virtio_net_hash_config > structure, > just set a separate structure for VIRTIO_NET_F_HASH_TUNNEL and include > hash_tunnel_types? The part that I am missing is, how do to reuse virtio_net_hash_config and say ignore all the existing fields related to rss, but only consider hash_tunnel_types?
[virtio-dev] RE: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
> From: Heng Qi
> Sent: Tuesday, February 21, 2023 8:34 AM
> > Even without a queue overflow, this shared receive queue may not have a
> balanced number of packets.
> > For example, tunnel-2 occupied 90% of the queue and left only 10% for
> tunnel-1.
> > So, your example is right (and extreme), a generic mention of QoS covers
> both aspects.
> >
> > Secondly "user inside the tunnel" is challenging to explain.
> > In above sentence talks specifically about the "receive queue" as an object.
> >
>
> "overflow" in my example. If we only use a one-sentence summary to describe
> tunnel risks, then I think this subparagraph is called "QoS problem for tunnel
> hash".
>
Yes, Tunnel Qos limitations
> >> 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 so, virtio_net_hash_config does not require hash_tunnel_types when
> >> it does not need to configure the specific tunnel(s).
> >>
> >>> If the intent is to enable hashing for the specific tunnel(s), an
> >>> individual
> >> command is better.
> >>
> >> Drivers MAY filter out some tunneling types when negotiating this feature.
> >> Do you think it would be better for us to add a separate command? I
> >> don't see tools like ethtool that can configure specific tunnels in
> >> userspace.
> >>
> > The reason I proposed different command is, Let's say we have only
> > single command.
> > Rss config command has many other fields unrelated to the inner hash.
>
> Yes. For inner hash, fields such as indirection table are irrelevant.
>
Right.
> > Hence, to enable inner hash, the driver needs to supply the exact same value
> for unrelated fields to the same value.
> > And device needs to compare it with the old value and maintain some sort of
> cache to derive that nothing changes from the previous hash config, hence,
> ignore hw configuration for rss.
> >
> > This mechanism slows down the command for the unrelated task.
>
> Totally agree.
>
> > Hence, I am considering a separate command that would be simple for the
> device and driver to implement.
>
> I agree with you. Do you want me to do it in this patch, or should we do it in
> another patch?
>
It should be in this patch set because enablement in the device is linked to
this capability exposed in this patch.
From patch split point of view,
Patch-1 to introduce the feature bit, description, and link to CVQ dependency.
Patch-2 for its link in virtio_net_config structure and description.
Patch-3 for new command touching control VQ pieces.
We can always squash the patch to single when/if it is hard to understand in
multiple patches.
Re: [virtio-dev] RE: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
在 2023/2/21 下午8:47, Parav Pandit 写道:
From: virtio-comm...@lists.oasis-open.org On Behalf Of Heng Qi
Also, a feature bit VIRTIO_NET_F_HASH_REPORT_TUNNEL are added to
report an encapsulation type, and the feature depends on
VIRTIO_NET_F_HASH_REPORT.
As we discussed that tunnel type alone is not useful the sw, neither as an
individual field nor merged with some other field.
Hence, please remove this feature bit. HASH_TUNNEL is good enough.
Please remove the references to it at more places below.
If we don't want it at all, I'll remove it and references to it.
Ok. thanks.
[..]
#define VIRTIO_NET_HASH_TYPE_UDP_EX(1 << 8)
\end{lstlisting}
Lets please remove the below encoding.
Here is the encoding of the hash tunnel types, I guess you are referring to
remove the encoding of the hash_report_tunnel types?
Right.
[..]
+RSS to select queues for placement. When a user inside a tunnel
+tries to control the enqueuing of encapsulated packets, then the
+user can flood the device with invaild packets, and the flooded
+packets may be hashed into the same queue as packets in other normal
+tunnels, which causing
the queue to overflow.
Invalid packets are confusing and the wording of "which causing" is not
proper.
There is some duplicate wording below too.
I think above and below risk can be summarized in bit simpler manner.
How about,
When a specific receive queue is shared to receive packets of multiple
tunnels, there is no quality of service for packets of multiple tunnels.
+
I think this sentence can be used as a starting summary, and readers may still
need to expand the explanation.
Do you think the following description is ok?
"
When a specific receive queue is shared to receive encapsulating packets of
multiple tunnels, there is no quality of service for these packets of multiple
tunnels.
For example:
A user inside the tunnel floods a device with packets, then the packets are
hashed into the shared receive queue and cause the queue to overflow, and
this increases packet loss and latency for other tunnels.
"
Even without a queue overflow, this shared receive queue may not have a
balanced number of packets.
For example, tunnel-2 occupied 90% of the queue and left only 10% for tunnel-1.
So, your example is right (and extreme), a generic mention of QoS covers both
aspects.
Secondly "user inside the tunnel" is challenging to explain.
In above sentence talks specifically about the "receive queue" as an object.
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 so, virtio_net_hash_config does not require hash_tunnel_types when it does
not need to configure the specific tunnel(s).
If the intent is to enable hashing for the specific tunnel(s), an individual
command is better.
Drivers MAY filter out some tunneling types when negotiating this feature.
Do you think it would be better for us to add a separate command? I don't see
tools like ethtool that can configure specific tunnels in userspace.
The reason I proposed different command is,
Let's say we have only single command.
Rss config command has many other fields unrelated to the inner hash.
And virtio_net_hash_config seems to suffice except for le16 reserved[4].
Hence, to enable inner hash, the driver needs to supply the exact same value
for unrelated fields to the same value.
And device needs to compare it with the old value and maintain some sort of
cache to derive that nothing changes from the previous hash config, hence,
ignore hw configuration for rss.
This mechanism slows down the command for the unrelated task.
Hence, I am considering a separate command that would be simple for the device
and driver to implement.
Regardless, this new field cannot be in the middle of the new structure as it
breaks backward compatibility.
Yes, you are right. I'll fix this.
Thank you very much!
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
在 2023/2/21 下午8:47, Parav Pandit 写道:
From: virtio-comm...@lists.oasis-open.org On Behalf Of Heng Qi
Also, a feature bit VIRTIO_NET_F_HASH_REPORT_TUNNEL are added to
report an encapsulation type, and the feature depends on
VIRTIO_NET_F_HASH_REPORT.
As we discussed that tunnel type alone is not useful the sw, neither as an
individual field nor merged with some other field.
Hence, please remove this feature bit. HASH_TUNNEL is good enough.
Please remove the references to it at more places below.
If we don't want it at all, I'll remove it and references to it.
Ok. thanks.
[..]
#define VIRTIO_NET_HASH_TYPE_UDP_EX(1 << 8)
\end{lstlisting}
Lets please remove the below encoding.
Here is the encoding of the hash tunnel types, I guess you are referring to
remove the encoding of the hash_report_tunnel types?
Right.
[..]
+RSS to select queues for placement. When a user inside a tunnel
+tries to control the enqueuing of encapsulated packets, then the
+user can flood the device with invaild packets, and the flooded
+packets may be hashed into the same queue as packets in other normal
+tunnels, which causing
the queue to overflow.
Invalid packets are confusing and the wording of "which causing" is not
proper.
There is some duplicate wording below too.
I think above and below risk can be summarized in bit simpler manner.
How about,
When a specific receive queue is shared to receive packets of multiple
tunnels, there is no quality of service for packets of multiple tunnels.
+
I think this sentence can be used as a starting summary, and readers may still
need to expand the explanation.
Do you think the following description is ok?
"
When a specific receive queue is shared to receive encapsulating packets of
multiple tunnels, there is no quality of service for these packets of multiple
tunnels.
For example:
A user inside the tunnel floods a device with packets, then the packets are
hashed into the shared receive queue and cause the queue to overflow, and
this increases packet loss and latency for other tunnels.
"
Even without a queue overflow, this shared receive queue may not have a
balanced number of packets.
For example, tunnel-2 occupied 90% of the queue and left only 10% for tunnel-1.
So, your example is right (and extreme), a generic mention of QoS covers both
aspects.
Secondly "user inside the tunnel" is challenging to explain.
In above sentence talks specifically about the "receive queue" as an object.
"overflow" in my example. If we only use a one-sentence summary to
describe tunnel risks, then I think this subparagraph is called "QoS
problem for tunnel hash".
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 so, virtio_net_hash_config does not require hash_tunnel_types when it does
not need to configure the specific tunnel(s).
If the intent is to enable hashing for the specific tunnel(s), an individual
command is better.
Drivers MAY filter out some tunneling types when negotiating this feature.
Do you think it would be better for us to add a separate command? I don't see
tools like ethtool that can configure specific tunnels in userspace.
The reason I proposed different command is,
Let's say we have only single command.
Rss config command has many other fields unrelated to the inner hash.
Yes. For inner hash, fields such as indirection table are irrelevant.
Hence, to enable inner hash, the driver needs to supply the exact same value
for unrelated fields to the same value.
And device needs to compare it with the old value and maintain some sort of
cache to derive that nothing changes from the previous hash config, hence,
ignore hw configuration for rss.
This mechanism slows down the command for the unrelated task.
Totally agree.
Hence, I am considering a separate command that would be simple for the device
and driver to implement.
I agree with you. Do you want me to do it in this patch, or should we do
it in another patch?
Thanks! :)
Regardless, this new field cannot be in the middle of the new structure as it
breaks backward compatibility.
Yes, you are right. I'll fix this.
Thank you very much!
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] RE: [virtio-comment] RE: [PATCH v9] virtio-net: support inner header hash
> From: virtio-comm...@lists.oasis-open.org open.org> On Behalf Of Heng Qi
> >> Also, a feature bit VIRTIO_NET_F_HASH_REPORT_TUNNEL are added to
> >> report an encapsulation type, and the feature depends on
> >> VIRTIO_NET_F_HASH_REPORT.
> > As we discussed that tunnel type alone is not useful the sw, neither as an
> individual field nor merged with some other field.
> > Hence, please remove this feature bit. HASH_TUNNEL is good enough.
> > Please remove the references to it at more places below.
>
> If we don't want it at all, I'll remove it and references to it.
>
Ok. thanks.
[..]
> >> #define VIRTIO_NET_HASH_TYPE_UDP_EX(1 << 8)
> >> \end{lstlisting}
> >>
> > Lets please remove the below encoding.
>
> Here is the encoding of the hash tunnel types, I guess you are referring to
> remove the encoding of the hash_report_tunnel types?
>
Right.
[..]
> >> +RSS to select queues for placement. When a user inside a tunnel
> >> +tries to control the enqueuing of encapsulated packets, then the
> >> +user can flood the device with invaild packets, and the flooded
> >> +packets may be hashed into the same queue as packets in other normal
> >> +tunnels, which causing
> >> the queue to overflow.
> >>
> > Invalid packets are confusing and the wording of "which causing" is not
> proper.
> > There is some duplicate wording below too.
> >
> > I think above and below risk can be summarized in bit simpler manner.
> >
> > How about,
> >
> > When a specific receive queue is shared to receive packets of multiple
> tunnels, there is no quality of service for packets of multiple tunnels.
> >
> > +
>
> I think this sentence can be used as a starting summary, and readers may still
> need to expand the explanation.
> Do you think the following description is ok?
> "
> When a specific receive queue is shared to receive encapsulating packets of
> multiple tunnels, there is no quality of service for these packets of multiple
> tunnels.
> For example:
> A user inside the tunnel floods a device with packets, then the packets are
> hashed into the shared receive queue and cause the queue to overflow, and
> this increases packet loss and latency for other tunnels.
> "
Even without a queue overflow, this shared receive queue may not have a
balanced number of packets.
For example, tunnel-2 occupied 90% of the queue and left only 10% for tunnel-1.
So, your example is right (and extreme), a generic mention of QoS covers both
aspects.
Secondly "user inside the tunnel" is challenging to explain.
In above sentence talks specifically about the "receive queue" as an object.
> 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 so, virtio_net_hash_config does not require hash_tunnel_types when it does
> not need to configure the specific tunnel(s).
>
> >
> > If the intent is to enable hashing for the specific tunnel(s), an individual
> command is better.
>
> Drivers MAY filter out some tunneling types when negotiating this feature.
> Do you think it would be better for us to add a separate command? I don't see
> tools like ethtool that can configure specific tunnels in userspace.
>
The reason I proposed different command is,
Let's say we have only single command.
Rss config command has many other fields unrelated to the inner hash.
Hence, to enable inner hash, the driver needs to supply the exact same value
for unrelated fields to the same value.
And device needs to compare it with the old value and maintain some sort of
cache to derive that nothing changes from the previous hash config, hence,
ignore hw configuration for rss.
This mechanism slows down the command for the unrelated task.
Hence, I am considering a separate command that would be simple for the device
and driver to implement.
> >
> > Regardless, this new field cannot be in the middle of the new structure as
> > it
> breaks backward compatibility.
> >
>
> Yes, you are right. I'll fix this.
>
> Thank you very much!
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
