On Wed, Mar 15, 2023 at 07:06:53PM -0400, Parav Pandit wrote: > > > On 3/15/2023 9:19 AM, Heng Qi wrote: > > > > > >在 2023/3/15 上午11:23, Parav Pandit 写道: > >> > >> > >>On 3/6/2023 10:48 AM, Heng Qi wrote: > >> > [..] > >>> \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ. > >>>+\item[VIRTIO_NET_F_HASH_TUNNEL] Requires VIRTIO_NET_F_CTRL_VQ. > >>I think this should also say that HASH_TUNNEL requires either of > >>the F_RSS or F_HASH_REPORT. > >>Because without it HASH_TUNNEL is not useful. > > > >F_HASH_TUNNEL indicates that the hash should be calculated using > >the inner packet header, even without F_RSS or F_HASH_REPORT, > >we can continue to use the hash value in scenarios such as RPS or > >ebpf programs. > Yes. > Even for rps or ebpf programs, F_HASH_TUNNEL is fine. > When such feature arrives in future, it above line will have OR > condition for RPS feature bit. > > > > > > >I think it's fine to let F_HASH_TUNNEL rely on F_RSS or > >_F_HASH_REPORT as those are probably important scenarios where > >inner packet header hash is used. > Yes. > > >>If not, for now it may be better to skip vxlan and nvegre as > >>they inherently have unique outer header UDP src port based on > >>the inner header. > > > >Symmetric hashing ignores the order of the five-tuples when > >calculating the hash, that is, using (a1,a2,p1,p2) and > >(a2,a1,p2,p1) respectively can calculate the same hash. > >There is a scenario that the two directions client1->client2 and > >client2->client1 of the same flow may pass through different > >tunnels. > >In order to allow the data in two directions to be processed by > >the same CPU, we need to calculate a symmetric hash based on the > >inner packet header. > I am lost in two directions and two clients above. > When you say two directions, do you mean tx and rx? > and do symmetric hashing between tx and rx between two end points > within single tunnel? >
A rough description of this scene is as follows: Client1 sends packets to client2, and client2 sends packets to client1 respectively. This is called two directions, and they are in the same flow. The packets in the two directions may reach the processing host through different tunnels. In this scenario, we need to hash these packets to the same queue for the same cpu to process, so inner symmetric hashing is required. client1 client2 | | | __________ | +----->| tunnels |<-------+ |---------| | | | | | | v v +-----------------+ | processing host | +-----------------+ > >>>+\field{hash_tunnel_types} is set to > >>>VIRTIO_NET_HASH_TUNNEL_TYPE_NONE by the device for the > >>>+unencapsulated packets. > >>>+ > I missed this before. unencapsulated is not a term. > s/unencapsulated packets/Non encapsulated packets or non tunneled packets > Yes, you are right! Thanks. > This publicly archived list offers a means to provide input to the > OASIS Virtual I/O Device (VIRTIO) TC. > > In order to verify user consent to the Feedback License terms and > to minimize spam in the list archive, subscription is required > before posting. > > Subscribe: virtio-comment-subscr...@lists.oasis-open.org > Unsubscribe: virtio-comment-unsubscr...@lists.oasis-open.org > List help: virtio-comment-h...@lists.oasis-open.org > List archive: https://lists.oasis-open.org/archives/virtio-comment/ > Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf > List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists > Committee: https://www.oasis-open.org/committees/virtio/ > Join OASIS: https://www.oasis-open.org/join/ --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org