DPDK usage discussions
 help / color / Atom feed
* [dpdk-users] Run To Completion Vs Pipeline
@ 2020-07-20  5:03 Prashanth Fernando
  2020-07-20 15:08 ` Stephen Hemminger
  0 siblings, 1 reply; 3+ messages in thread
From: Prashanth Fernando @ 2020-07-20  5:03 UTC (permalink / raw)
  To: users

Hi,

I'm wondering why DPDK proposes 2 different models.
Is there any situation that fits one model but not another?

I am looking to build an application with a firewall, regex, LPM, rate-limiters etc ...
I am wondering which approach would be a best fit for my usecase.


Thanks,
Prashanth


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-users] Run To Completion Vs Pipeline
  2020-07-20  5:03 [dpdk-users] Run To Completion Vs Pipeline Prashanth Fernando
@ 2020-07-20 15:08 ` Stephen Hemminger
  2020-07-21  7:01   ` Pierre
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2020-07-20 15:08 UTC (permalink / raw)
  To: Prashanth Fernando; +Cc: users

On Mon, 20 Jul 2020 05:03:55 +0000
Prashanth Fernando <prashanth.fernando@tatacommunications.com> wrote:

> Hi,
> 
> I'm wondering why DPDK proposes 2 different models.
> Is there any situation that fits one model but not another?
> 
> I am looking to build an application with a firewall, regex, LPM, rate-limiters etc ...
> I am wondering which approach would be a best fit for my usecase.
> 
> 
> Thanks,
> Prashanth
> 

There are two different factors here.
First, how many cores do you have to burn. The run to completion model uses
less cores (and has less latency). But other models are better if some set
of packets require longer to process (VPN, Crypto, ...) in that case you
want to push packets to other core.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-users] Run To Completion Vs Pipeline
  2020-07-20 15:08 ` Stephen Hemminger
@ 2020-07-21  7:01   ` Pierre
  0 siblings, 0 replies; 3+ messages in thread
From: Pierre @ 2020-07-21  7:01 UTC (permalink / raw)
  To: users; +Cc: prashanth.fernando

HI

In a run-to-completion simple model on a single core,

    - you have full control of the execution order and packet 
transmission order, typically being strictly the same than reception order.

   - simple model to make it easy to debug and learn DPDK code.

   - simple model to get deterministic latencies.

   - will not scale easily, because the bottleneck is the whole sw.

In a simple pipeline model,

   - execution order get less deterministic .

     If the problems to solve are stateless (no dependency between 
packets), that might be ok,

     extreme scalability is easy to achieve.

   - you need queues between pipelined components. You have to handle 
overflows and bottlenecks,

     and decisions to throttle and drop traffic is yours.

    - you might wish to use priority queues, i.e. much more complex 
design with its own drawbacks

      and failure cases , and debugging uncertainties. Latencies get 
hairy to analyse.


There are all intermediates between these extremes , e.g. pipelining 
across multiple  run-to-completion stateful subsystems

- stateful TCP reordering and reassembly,

- IP reordering and reassembly, IPSec , fragmentations  between networks 
with different mtus

- UDP reassembly before regex

- IGMP packets and multicast packets

- ...... all the networking fun .....

  - and you have to design your subsystem to best fit workloads vs. 
processing power of each core.


you could switch dynamically from one model to the other one depending 
on traffic rates

- at low traffic rate, get the best use of a single core and save the 
maximum of power on the system

   this would favour a run-to-completion model at run time.

- at high traffic rate, wake up multiple cores

    this would favour a piplining model at run time.



On 20/07/2020 16:08, Stephen Hemminger wrote:
> On Mon, 20 Jul 2020 05:03:55 +0000
> Prashanth Fernando <prashanth.fernando@tatacommunications.com> wrote:
>
>> Hi,
>>
>> I'm wondering why DPDK proposes 2 different models.
>> Is there any situation that fits one model but not another?
>>
>> I am looking to build an application with a firewall, regex, LPM, rate-limiters etc ...
>> I am wondering which approach would be a best fit for my usecase.
>>
>>
>> Thanks,
>> Prashanth
>>
> There are two different factors here.
> First, how many cores do you have to burn. The run to completion model uses
> less cores (and has less latency). But other models are better if some set
> of packets require longer to process (VPN, Crypto, ...) in that case you
> want to push packets to other core.

-- 
Emutex Limited, Roselawn House, National Technology Park, Limerick, V94 6R68, Ireland.
Phone: +353 (0)61 514496 Ext# 814, Web: www.emutex.com.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-20  5:03 [dpdk-users] Run To Completion Vs Pipeline Prashanth Fernando
2020-07-20 15:08 ` Stephen Hemminger
2020-07-21  7:01   ` Pierre

DPDK usage discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ http://inbox.dpdk.org/users \
		users@dpdk.org
	public-inbox-index users


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.users


AGPL code for this site: git clone https://public-inbox.org/ public-inbox