On 1/29/2024 3:08 PM, Etelson, Gregory wrote:
> Hello Ferruh,
>
>>
>> Hi Gregory, Ori,
>>
>> Why we need three separate APIs,
>> rte_flow_template_table_resize
>> rte_flow_async_update_resized
>> rte_flow_template_table_resize_complete
>>
>> Why not 'rte_flow_template_table_resize()' update existing flows and
>> release resources related to the original tables automatically?
>>
>
>
> Template table resize API allows to add new flows immediately after
> rte_flow_template_table_resize completed.
> A multi-threaded application can add new and update old flows
> simultaneously.
>
> A single resize-and-update API would require to lock PMD for entire
> operation.
> For application with 1e6 flows doubling a table would end up with
> considerable down time.
>
If a multi-threaded application can add new and updated old
simultaneously, this should be done via monolithic API, like:
{
lock
resize
unlock
for each flow
lock
update
unlock
}
Perhaps questions is, is there a usecase that user does the resize but
doesn't want to update the old flows?
> The rte_flow_template_table_resize_complete was added for PMDs that
> cannot differentiate flows created before and after table resize.
>
Can you please elaborate this?
Does it mean old flows and new flows require different handling and PMD
doesn't know how to differentiate old and new flows?
If so how update() converts old flows, there must be a way for driver to
differentiate them for update() to work.
Also if resize_complete() NOT called at all, does this mean PMD can't
handle any flows anymore as it can't differentiate old and new ones?
