From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Nikhil Rao <nikhil.rao@intel.com>
Cc: hemant.agrawal@nxp.com, dev@dpdk.org, narender.vangati@intel.com,
abhinandan.gujjar@intel.com, gage.eads@intel.com
Subject: Re: [dpdk-dev] [RFC] eventdev: event tx adapter APIs
Date: Wed, 30 May 2018 12:56:37 +0530 [thread overview]
Message-ID: <20180530072633.GA2015@jerin> (raw)
In-Reply-To: <1527260924-86922-1-git-send-email-nikhil.rao@intel.com>
-----Original Message-----
> Date: Fri, 25 May 2018 20:38:44 +0530
> From: Nikhil Rao <nikhil.rao@intel.com>
> To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com
> CC: dev@dpdk.org, narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> gage.eads@intel.com, Nikhil Rao <nikhil.rao@intel.com>
> Subject: [RFC] eventdev: event tx adapter APIs
> X-Mailer: git-send-email 1.8.3.1
>
> The patch below introduces the event tx adapter APIs that encapsulate common
> code for the tx stage of a packet processing pipeline. These APIs allow
> the application to configure a rte_service function that reads mbuf events
> from an event queue and sends mbufs on the transmit queue and ethernet
> port specified in the mbuf private area.
>
Hi Nikhil,
I think, it is reasonable to have Tx adapter.
Some top level comments to starts with,
1) Slow path API looks fine. The only comment is, How about changing
rte_event_eth_tx_adapter_queue_add() instead of rte_event_eth_tx_adapter_queue_start()
to get align with Rx adapter?
2) This my understanding of fastpath
a) Common code will have a extra port(given through adapter create)
where all workers invoke rte_event_enqueue_burst() to that port and then common code
dequeue from that port and send packet
using rte_eth_tx_burst() and/or using tx buffering APIs
b) If the source queue or sched_type is ORDERED, When it enqueue to the extra port it
will change to atomic/direct to maintain the the ingress order if need.
Couple of issues and a minor change in RFC to fix the issues as a proposal.
Issue 1) I think, Using mbuf private data for such purpose will be a problem as
exiting application already may using for it own needs and there will be additional cache
miss etc on fastpath to get private data.
Issue 2) At least on Cavium, We can do so optimization by introducing
the same RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT schematics of Rx
adapter. i.e we don't need extra port to converge all traffic from
different workers and transmit.
Considering above two issues2, We would like propose an fastpath API,
which semantics is almost same rte_ethdev_tx_burst().
a) It will get ride of mbuf metadata need
b) New fastpath API gives driver enough possibilities of optimization if
possible.(address the issue (2))
The API can be like,
uint16_t rte_event_eth_tx_adapter_enqueue(uint16_t eth_port_id, uint16_t
eth_queue_id, uint8_t event_port_id, const struct rte_event ev[], uint16_t nb_events);
This API would land in driver as function pointer if device has
RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT capability.
If device does not have !RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT then
common code can choose to ignore event_port_id in
rte_event_eth_tx_adapter_enqueue() and select the port given in adapter
create in common code.
So from the top-level, each worker lcore will look like
while(1)
{
rte_event_dequeue_burst(..,worker[port],..);
(process the packets)
rte_event_eth_tx_adapter_enqueue(... worker[port],...);
}
Thoughts?
next prev parent reply other threads:[~2018-05-30 7:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 15:08 Nikhil Rao
2018-05-30 7:26 ` Jerin Jacob [this message]
2018-06-01 18:17 ` Rao, Nikhil
2018-06-04 5:11 ` Jerin Jacob
2018-06-05 9:24 ` Rao, Nikhil
2018-06-10 12:05 ` Jerin Jacob
2018-06-10 12:12 ` Jerin Jacob
2018-06-12 21:32 ` [dpdk-dev] [RFC v2] " Nikhil Rao
2018-06-14 12:09 ` Rao, Nikhil
2018-06-17 11:09 ` Jerin Jacob
2018-06-18 12:10 ` Rao, Nikhil
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=20180530072633.GA2015@jerin \
--to=jerin.jacob@caviumnetworks.com \
--cc=abhinandan.gujjar@intel.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=narender.vangati@intel.com \
--cc=nikhil.rao@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).