Re: rte_event_eth_tx_adapter_enqueue() short enqueue

["Mattias Rönnblom" <hofors@lysator.liu.se>]

On 2024-11-27 11:38, Bruce Richardson wrote:
> On Wed, Nov 27, 2024 at 11:03:31AM +0100, Mattias Rönnblom wrote:
>> Hi.
>>
>> Consider the following situation:
>>
>> An application does
>>
>> rte_event_eth_tx_adapter_enqueue()
>>
>> and due to back-pressure or some other reason not all events/packets could
>> be enqueued, and a count lower than the nb_events input parameter is
>> returned.
>>
>> The API says that "/../ the remaining events at the end of ev[] are not
>> consumed and the caller has to take care of them /../".
>>
>> May an event device rearrange the ev array so that any enqueue failures are
>> put last in the ev array?
>>
>> In other words: does the "at the end of ev[]" mean "at the end of ev[] as
>> the call has completed", or is the event array supposed to be untouched, and
>> thus the same events are at the end both before and after the call.
>>
>> The ev array pointer is not const, so from that perspective it may be
>> modified.
>>
>> This situation may occur for example the bonding driver is used under the
>> hood. The bonding driver does this kind of rearrangements on the ethdev
>> level.
>>
> 
> Interesting question. I tend to think that we should not proclude this
> reordering, as it should allow e.g  an eventdev which is short on space to
> selectively enqueue only the high priority events.
> 

Allowing reordering may be a little surprising to the user. At least it 
would be for me.

Other eventdev APIs enqueue do not allow this kind of reordering (with 
const-marked arrays).

That said, I lean toward agreeing with you, since it will solve the 
ethdev tx_burst() mapping issue mentioned.

> Only caveat is that if we do allow the reordering we clarify the
> documentation to explicitly state that it is allowed.
> 
> /Bruce