From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [RFC] examples: remove l3fwd-vf example
Date: Wed, 20 Apr 2016 12:46:46 +0200
Message-ID: <4008817.HUC273QNcu@xps13>
References: <1436860647-5862-1-git-send-email-jingjing.wu@intel.com>
 <533710CFB86FA344BFBF2D6802E60286046FF05F@SHSMSX101.ccr.corp.intel.com>
 <2601191342CEEE43887BDE71AB97725836A6DCA7@irsmsx105.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: "Qiu, Michael" <michael.qiu@intel.com>, "Zhang,
 Helin" <helin.zhang@intel.com>, "Liu, Yong" <yong.liu@intel.com>, "Cao,
 Waterman" <waterman.cao@intel.com>, dev@dpdk.org
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
 by dpdk.org (Postfix) with ESMTP id 4D82C2C00
 for <dev@dpdk.org>; Wed, 20 Apr 2016 12:46:48 +0200 (CEST)
Received: by mail-wm0-f51.google.com with SMTP id u206so74351046wme.1
 for <dev@dpdk.org>; Wed, 20 Apr 2016 03:46:48 -0700 (PDT)
In-Reply-To: <2601191342CEEE43887BDE71AB97725836A6DCA7@irsmsx105.ger.corp.intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2015-08-04 17:12, Ananyev, Konstantin:
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiu, Michael
> > Actually, l3fwd works fine with fm10k vf.
> > 
> > I don't know what's the exact reason of l3fwd-vf still in DPDK,
> > at least we could make full support for vf in l3fwd instead of another
> > sample with most code are the same compare with l3fwd.
> 
> Right now, l3fwd is not able to work properly for cases where number of forwarding  lcores 
> exceeds number of tx queues on any active port.
> As an example: 
> 2 forwarding lcores and a port with just 1 TX queue (e1000 legacy device).
> 
>  To make l3fwd work for such cases you need to add some sort of synchronisation on TX path.
>  Which means one of 2 ways:
>  either introduce different TX path into l3fwd (one with sync if legacy/virual device is used, another without)
>  and select it on process startup/config phase,
>  or sync overhead for fastpath.

Any news about removing l3fwd-vf example?

l3fwd has been reworked but l3fwd-power, l3fwd-vf and l3fwd-thread are
still based on the old l3fwd with APP_LOOKUP_METHOD compile-time flag.