Soft Patch Panel
 help / color / mirror / Atom feed
From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: "spp@dpdk.org" <spp@dpdk.org>
Subject: Re: [spp] secondary applications
Date: Fri, 23 Feb 2018 16:43:17 +0900	[thread overview]
Message-ID: <20dd4421-5a82-93ca-e270-2a09a3a9fedb@lab.ntt.co.jp> (raw)
In-Reply-To: <d4523a70-b873-a322-8e26-38a57fc3af8d@intel.com>

On 2018/02/22 20:53, Ferruh Yigit wrote:
> Hi Yasufumi,
> 
> For primary process there is single binary, but for secondary there are three now:
> nfv
> vf
> vm
> 
> and from their name it is not clear what they are for and what is the difference.
SPP was started as a trial PoC app and name convention was not 
considered well. I think it must be revised.

> 
> Do you know what is the difference between them?
nfv and vm are simply forwarding and almost same but different for 
running on host or guest. In addition, vm behaves as secondary but 
implemented as primary in guest actually.

On the other hand, vf is including worker thread for classifying or 
merging packets for more realistic usecases.
> 
> 
> And does it make sense to merge them into single binary, to escape from
> maintaining three different binaries? Or can we eliminate some?
I think vf might be merged to nfv. I agree with you to reduce 
maintaining costs, so I'd like to try to consider it.

I have already refactored spp.py first because all of classes and 
methods are included in one file which makes maintaining so hard, and 
usability is poor. After done refactoring spp.py, I will start 
refactoring for secondary including name convention.

Thanks
> 
> Thanks,
> ferruh
> 
> 


-- 
Yasufumi Ogawa
NTT Network Service Systems Labs

      reply	other threads:[~2018-02-23  7:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-22 11:53 Ferruh Yigit
2018-02-23  7:43 ` Yasufumi Ogawa [this message]

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=20dd4421-5a82-93ca-e270-2a09a3a9fedb@lab.ntt.co.jp \
    --to=ogawa.yasufumi@lab.ntt.co.jp \
    --cc=ferruh.yigit@intel.com \
    --cc=spp@dpdk.org \
    /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).