DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: "Jerin Jacob Kollanukkaran" <jerinj@marvell.com>,
	"Daniel Östman" <daniel.ostman@ericsson.com>,
	"Naga Harish K S V" <s.v.naga.harish.k@intel.com>,
	nils.wiberg@ericsson.com, gyumin.hwang@ericsson.com,
	changshik.lee@ericsson.com,
	"Mattias Rönnblom" <mattias.ronnblom@ericsson.com>
Subject: rte_event_eth_tx_adapter_enqueue() short enqueue
Date: Wed, 27 Nov 2024 11:03:31 +0100	[thread overview]
Message-ID: <903aa783-5956-4020-b2a0-48def17fe03f@lysator.liu.se> (raw)

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.

Thanks,
	Mattias

             reply	other threads:[~2024-11-27 10:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-27 10:03 Mattias Rönnblom [this message]
2024-11-27 10:38 ` Bruce Richardson
2024-11-27 10:53   ` Mattias Rönnblom
2024-11-27 11:07     ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=903aa783-5956-4020-b2a0-48def17fe03f@lysator.liu.se \
    --to=hofors@lysator.liu.se \
    --cc=changshik.lee@ericsson.com \
    --cc=daniel.ostman@ericsson.com \
    --cc=dev@dpdk.org \
    --cc=gyumin.hwang@ericsson.com \
    --cc=jerinj@marvell.com \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=nils.wiberg@ericsson.com \
    --cc=s.v.naga.harish.k@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).