> -----Original Message-----
> From: Pavan Nikhilesh Bhagavatula <pbhagavat...@marvell.com>
> Sent: Friday, September 27, 2019 8:05 PM
> To: Nipun Gupta <nipun.gu...@nxp.com>; Jerin Jacob Kollanukkaran
> <jer...@marvell.com>; bruce.richard...@intel.com; Akhil Goyal
> <akhil.go...@nxp.com>; Marko Kovacevic <marko.kovace...@intel.com>;
> Ori Kam <or...@mellanox.com>; Radu Nicolau <radu.nico...@intel.com>;
> Tomasz Kantecki <tomasz.kante...@intel.com>; Sunil Kumar Kori
> <sk...@marvell.com>
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v4 08/10] examples/l2fwd-event: add
> eventdev main loop
> 
> >>
> >> From: Pavan Nikhilesh <pbhagavat...@marvell.com>
> >>
> >> Add event dev main loop based on enabled l2fwd options and
> >eventdev
> >> capabilities.
> >>
> >> Signed-off-by: Pavan Nikhilesh <pbhagavat...@marvell.com>
> >> ---
> >
> ><snip>
> >
> >> +          if (flags & L2FWD_EVENT_TX_DIRECT) {
> >> +                  rte_event_eth_tx_adapter_txq_set(mbuf, 0);
> >> +                  while
> >> (!rte_event_eth_tx_adapter_enqueue(event_d_id,
> >> +                                                          port_id,
> >> +                                                          &ev, 1)
> >&&
> >> +                                  !*done)
> >> +                          ;
> >> +          }
> >
> >In the TX direct mode we can send packets directly to the ethernet
> >device using ethdev
> >API's. This will save unnecessary indirections and event unfolds within
> >the driver.
> 
> How would we guarantee atomicity of access to Tx queues? Between cores
> as we can only use one Tx queue.
> Also, if SCHED_TYPE is ORDERED how would we guarantee flow ordering?
> The capability of MT_LOCKFREE and flow ordering is abstracted through `
> rte_event_eth_tx_adapter_enqueue `.

I understand your objective here. Probably in your case the DIRECT is equivalent
to giving the packet to the scheduler, which will pass on the packet to the 
destined device.
On NXP platform, DIRECT implies sending the packet directly to the device 
(eth/crypto),
and scheduler will internally pitch in.
Here we will need another option to send it directly to the device.
We can set up a call to discuss the same, or send patch regarding this to you 
to incorporate
the same in your series.

> 
> @see examples/eventdev_pipeline and app/test-eventdev/test_pipeline_*.

Yes, we are aware of that, They are one way of representing, how to build a 
complete eventdev pipeline.
They don't work on NXP HW.
We plan to send patches for them to fix them for NXP HW soon.

Regards,
Nipun

> 
> >
> >> +
> >> +          if (timer_period > 0)
> >> +                  __atomic_fetch_add(&eventdev_rsrc-
> >>stats[mbuf-
> >> >port].tx,
> >> +                                     1, __ATOMIC_RELAXED);
> >> +  }
> >> +}

Reply via email to