* [dpdk-dev] Multiple LCore receiving from same port/queue
@ 2013-10-16 20:32 Sambath Kumar Balasubramanian
2013-10-16 21:06 ` Stephen Hemminger
2013-10-16 21:12 ` Vladimir Medvedkin
0 siblings, 2 replies; 4+ messages in thread
From: Sambath Kumar Balasubramanian @ 2013-10-16 20:32 UTC (permalink / raw)
To: dev
Hi,
I have a test dpdk application with 2 lcores receiving packets
using rte_eth_rx_burst API. Is this a supported packet processing model.
The reason I am asking is I am running into some trouble with this model.
Thanks,
Sambath
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] Multiple LCore receiving from same port/queue
2013-10-16 20:32 [dpdk-dev] Multiple LCore receiving from same port/queue Sambath Kumar Balasubramanian
@ 2013-10-16 21:06 ` Stephen Hemminger
2013-10-16 21:12 ` Vladimir Medvedkin
1 sibling, 0 replies; 4+ messages in thread
From: Stephen Hemminger @ 2013-10-16 21:06 UTC (permalink / raw)
To: Sambath Kumar Balasubramanian; +Cc: dev
On Wed, 16 Oct 2013 13:32:33 -0700
Sambath Kumar Balasubramanian <sambath.balasubramanian@gmail.com> wrote:
> Hi,
>
> I have a test dpdk application with 2 lcores receiving packets
> using rte_eth_rx_burst API. Is this a supported packet processing model.
> The reason I am asking is I am running into some trouble with this model.
>
> Thanks,
> Sambath
For performance reasons, receive and transmit functions are not thread safe.
You need to have one queue per lcore, or use locking.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] Multiple LCore receiving from same port/queue
2013-10-16 20:32 [dpdk-dev] Multiple LCore receiving from same port/queue Sambath Kumar Balasubramanian
2013-10-16 21:06 ` Stephen Hemminger
@ 2013-10-16 21:12 ` Vladimir Medvedkin
2013-10-16 21:37 ` Sambath Kumar Balasubramanian
1 sibling, 1 reply; 4+ messages in thread
From: Vladimir Medvedkin @ 2013-10-16 21:12 UTC (permalink / raw)
To: Sambath Kumar Balasubramanian; +Cc: dev
Hi,
By default, you can't poll same queue on same port from different lcores.
If you need poll same queue on several lcores use locks to avoid race
conditions.
2013/10/17 Sambath Kumar Balasubramanian <sambath.balasubramanian@gmail.com>
> Hi,
>
> I have a test dpdk application with 2 lcores receiving packets
> using rte_eth_rx_burst API. Is this a supported packet processing model.
> The reason I am asking is I am running into some trouble with this model.
>
> Thanks,
> Sambath
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] Multiple LCore receiving from same port/queue
2013-10-16 21:12 ` Vladimir Medvedkin
@ 2013-10-16 21:37 ` Sambath Kumar Balasubramanian
0 siblings, 0 replies; 4+ messages in thread
From: Sambath Kumar Balasubramanian @ 2013-10-16 21:37 UTC (permalink / raw)
To: Vladimir Medvedkin; +Cc: dev
Thanks Stephen and Vladimir. Appreciate the quick response.
Thanks,
Sambath
On Wed, Oct 16, 2013 at 2:12 PM, Vladimir Medvedkin <medvedkinv@gmail.com>wrote:
> Hi,
>
> By default, you can't poll same queue on same port from different lcores.
> If you need poll same queue on several lcores use locks to avoid race
> conditions.
>
>
> 2013/10/17 Sambath Kumar Balasubramanian <
> sambath.balasubramanian@gmail.com>
>
>> Hi,
>>
>> I have a test dpdk application with 2 lcores receiving packets
>> using rte_eth_rx_burst API. Is this a supported packet processing model.
>> The reason I am asking is I am running into some trouble with this model.
>>
>> Thanks,
>> Sambath
>>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-10-16 21:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-16 20:32 [dpdk-dev] Multiple LCore receiving from same port/queue Sambath Kumar Balasubramanian
2013-10-16 21:06 ` Stephen Hemminger
2013-10-16 21:12 ` Vladimir Medvedkin
2013-10-16 21:37 ` Sambath Kumar Balasubramanian
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).