On Fri, Jan 22, 2021 at 02:18:34AM +0100, Pablo Neira Ayuso wrote: > Hi Oz, > > On Wed, Jan 20, 2021 at 06:09:48PM +0200, Oz Shlomo wrote: > > On 1/14/2021 11:50 PM, Marcelo Ricardo Leitner wrote: > > > > > > Thoughts? > > > > > > > I wonder if we should develop a generic mechanism to optimize CT software > > for a use case that is faulty by design. > > This has limited value for software as it would only reduce the conntrack > > table size (packet classification is still required). > > However, this feature may have a big impact on hardware offload. > > Normally hardware offload relies on software to handle new connections. > > Causing all new connections to be processed by software. > > With this patch the hardware may autonomously set the +new connection state > > for the relevant connections. > > Could you fix this issue with unidirectional flows by checking for > IPS_CONFIRMED status bit? The idea is to hardware offload the entry > after the first packet goes through software successfully. Then, there > is no need to wait for the established state that requires to see > traffic in both directions.
That's an interesting idea. This way, basically all that needs to be changed is tcf_ct_flow_table_process_conn() to handle this new condition for UDP packets and on tcf_ct_act(). It has a small performance penaulty if compared to the original solution, as now the first packet(s) goes to sw, but looks like a good compromise between supporting a (from what I could understand) somewhat lazy flow design (as I still think these didn't need to go through conntrack), an uniform system behavior (with and without offload, with mlx5 or another driver) and a more generic approach. Other situations that rely on unidirectional UDP flows will benefit from it as well. This way I even think it doesn't need to be configurable right now. It will be easier to add a knob to switch back to the old behavior if needed later on, if anything. Marcelo
