> >> >>> For section 18.1.1, I suggest RFS should be analyzed. E.g., if > >> >>> NIC want to do flow steering based on the inner header > >> >>> information, then it could use entropy value instead of the inner > >> >>> header > information. > >> >> Did you mean Receive Side Scaling (RSS)? That is mentioned in the > >> >> document - section 18.1.1 . Perhaps the RSS text can be improved. > >> >> Receive Flow Scaling is the name of a Linux software technique to > >> >> take into account the CPU on which the application is running, > >> >> which is > >> different. > >> > [Lizhong] I am referring to hardware based flow steering, similar > >> > with Accelerated RFS (Receive Flow Steering). In the NIC I/O > >> > virtualization, the NIC will directly trigger interrupt to the CPU > >> > where application is running by looking up a flow table. We will > >> > use the inner header to do the flow table lookup, if hardware could > >> > not parse the inner header, then entropy value in the encapsulation is > required. > >> Any design of hiding inner header information should consider above > >> implementation. > >> > > >> > >> I thought the purpose of RFS was to send the packet (and associated > >> interrupt) to the CPU where the application process is running. That > >> implies an exact flow lookup. Some hash value, whether computed by > >> the receiving NIC or whether in some entropy field in the packet > >> (computed by the sender or > >> encapsulator) would not suffice for that purpose. > > [Lizhong] right, hash value is not enough for flow steering. One > > possible way is to standardize one or two basic entropy generation > > algorithm, and encapsulation the information in the header. > > Please see my comments. The hash has to work with flow steering and this is > already how RFS works. If it doesn't work then the only alternative is that > devices will need to continue to do deep, protocol specific. parsing of all > the > different encapsulation protocols (GUE, Geneve, VXLAN, VXLAN-GPE, > MPLS/UDP, GRE/UDP, etc.)-- this complexity is exactly what we are trying to > avoid by allowing the UDP source port for entropy or IPv6 flow label if that > is > not sufficient. [Lizhong] Hi Tom, in Linux RFS, it does use rxhash value to index the flow table. And Linux also use the same rxhash value to program the flow table after receiving the packet. So the sequence is, first receive packet from a default CPU core, then program the flow table, and then steer the packet to the new core for subsequent packets. Current hardware flow steering provides two way to program the flow table: 1. program flow table by ndo_rx_flow_steer, then it is same as current linux way, and hash value could work in this way. 2. program by e.g., eth tool, then before receiving any packet, we could not program the entry, because we do not know the hash value. If we could standardize the entropy generation, then we could program before receiving any packet. This programming is usefull if we want to fix one application to be always on one core.
Regards Lizhong > > Tom > > > I know the encapsulation work may be unable to make every point in the > > network to be most optimized. But since it is a consideration > > document, it is necessary to raise the issue. And if it could be solved, it > > will be > beneficial for the performance of host system. > > > > > Regards > > Lizhong > > > >> > >> Of course, a hash value (e.g., from the entropy field) is useful for RSS. > >> > >> Regards, > >> Erik > > > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
