Hi Everyone,
I am thinking of a few enhancements to the existing GRO library and I have listed them below,
- The current implementation for the TCP in GRO disregards the PSH flag and delivers it immediately in the current burst. But this would lead to reordering of packets if there were ACK packets subjected to GRO. The peer could potentially think that these are out of order packets. I think this was done this way, keeping timer mode GRO in mind and the PSH packet was sent in the current burst. But can we enhance it in such a way that we merge the packet with PSH flag to the existing flow and mark the item in the table to be flushed immediately when rte_gro_timeout_flush is invoked. If we receive a packet with PSH flag set and there is no matching flow existing, we could flush the packet immediately. This would not cause out of order packets in an ideal case. It can be assumed that in ideal cases the rte_gro_timeout_flush would be invoked periodically and hence we have solved the packet reordering issues. Also in most of the cases, the TCP timestamp of the PSH packet would be the same as that of the previous ACK packets that are subjected to the GRO. I understand that we do not want to delay the packet with PSH flag set, but in general the PSH flag is set on the last segment of the packet, which means that the packets upto the PSH flag should be delivered immediately. But in the existing library we send the packet only with the PSH flag set. This could be handled for the static (inline mode) of GRO as well.
- The flow matching algorithm currently iterates over all the existing flows to check for a match. This could be changed to a HASH based lookup based on the TUPLE similar to the implementation in Linux Kernel, because with Timer mode GRO and if there are higher number of flows this would become costly. Also many applications in userspace would maintain a flowtable for the lookup based on Hash or Tree, from GRO layer can we provide an option where rather than using the default flow matching algorithm, we use the application's flow matching algorithm.
Please let me know your thoughts on the above proposal.
Thanks,
Kumara Parameshwaran