Re: [vpp-dev] DPDK plugin - port ID and index

2018-08-17 Thread Andrzej Ostruszka
On 17.08.2018 14:07, Damjan Marion wrote:
> Are you on some old vpp version?
> 
> We did recently what i think you are asking for, port_id is now
> decoupled from device_index...

Oh shoot!  Yes indeed our client is using older version of VPP - my bad
I should have checked current version.

Now I've found a059a000 - thank you and sorry for the noise.

Best regards
Andrzej
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10204): https://lists.fd.io/g/vpp-dev/message/10204
Mute This Topic: https://lists.fd.io/mt/24610614/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [vpp-dev] DPDK plugin - port ID and index

2018-08-17 Thread Damjan Marion via Lists.Fd.Io
Are you on some old vpp version?

We did recently what i think you are asking for, port_id is now decoupled from 
device_index...


-- 
Damjan

> On 17 Aug 2018, at 10:15, Andrzej Ostruszka  wrote:
> 
> Hello all
> 
> I'm new to VPP so please bear with my ignorance in its
> architecture/internals/development process :).
> 
> I'd like to ask for some change regarding DPDK plugin - to be specific
> to differentiate between "device index" (in device table) and "device
> id" (the DPDK port ID).  More information about the change is below and
> the proposed patch is in the attachment (since I'm not aware yet of the
> process to proposed them - if there is any).
> 
> The background for the change is as follows: I've developed a logical
> PMD for DPDK that is meant to split different type of traffic (read some
> "tag") to different "logical" ports while under the hood for actual
> transmission a "physical" port is used.  The driver on the RX side takes
> care of the finding the correct "logical" port for given tag, stripping
> it and passing to the port and on TX side its job is to insert the tag
> and pass it to the "physical" port for transmission.  It works with
> test-pmd and l2fwd DPDK applications but our customer wishes to use it
> also with VPP and here I needed to make some changes which I'd like to
> upstream now.
> 
> From the above description you can see that for N logical ports there
> are N+1 (at least) actual DPDK ports used.  So the situation is a bit
> like "reversed bonding driver" - in bonding PMD the are many "physical"
> ports that are grouped to form one "logical" link, and in my case this
> is reversed.
> 
> I've decided to make use of the new DPDK API "rte_eth_dev_owner_new/set"
> (introduced by commit 5b7ba31148a8b and still marked as "experimental")
> because this makes much easier for other applications (like VPP) to not
> depend on the internals of given PMD - for example I did not have to
> touch testpmd and l2fwd apps from DPDK to make them work since they were
> already using/compatible with the new API.
> 
> This however requires some changes in VPP to make it work.  Previously
> you simply assumed that DPDK port IDs start with 0 and assumed 1 to 1
> correspondence between index in internal table with DPDK port id.  With
> the use of some "internal/owned" DPDK ports this is no longer true so
> what I am proposing is to add 'device_id' to 'dpdk_device_t' and make
> use of it when passing to RTE functions and use 'RTE_ETH_FOREACH_DEV'
> macro instead of plain 'for' loops starting with 0.
> 
> The patch in the attachment is what I have used for our customer.  Note
> however that this was my first contact with VPP so there might be
> something wrong with it or I might have missed some other places that
> also need an update.  Also note that since the "ownership" API in DPDK
> is still marked as experimental then you'll need to add
> "-Wno-deprecated-declarations" to your compilation flags in platform
> files (I'm using a separate one so don't have patch for you).
> 
> Let me know what you think.
> 
> Best regards
> Andrzej
> <0001-plugins-dpdk-do-not-use-internal-index-for-port-id.patch>-=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#10193): https://lists.fd.io/g/vpp-dev/message/10193
> Mute This Topic: https://lists.fd.io/mt/24610614/675642
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10201): https://lists.fd.io/g/vpp-dev/message/10201
Mute This Topic: https://lists.fd.io/mt/24610614/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[vpp-dev] DPDK plugin - port ID and index

2018-08-17 Thread Andrzej Ostruszka
Hello all

I'm new to VPP so please bear with my ignorance in its
architecture/internals/development process :).

I'd like to ask for some change regarding DPDK plugin - to be specific
to differentiate between "device index" (in device table) and "device
id" (the DPDK port ID).  More information about the change is below and
the proposed patch is in the attachment (since I'm not aware yet of the
process to proposed them - if there is any).

The background for the change is as follows: I've developed a logical
PMD for DPDK that is meant to split different type of traffic (read some
"tag") to different "logical" ports while under the hood for actual
transmission a "physical" port is used.  The driver on the RX side takes
care of the finding the correct "logical" port for given tag, stripping
it and passing to the port and on TX side its job is to insert the tag
and pass it to the "physical" port for transmission.  It works with
test-pmd and l2fwd DPDK applications but our customer wishes to use it
also with VPP and here I needed to make some changes which I'd like to
upstream now.

>From the above description you can see that for N logical ports there
are N+1 (at least) actual DPDK ports used.  So the situation is a bit
like "reversed bonding driver" - in bonding PMD the are many "physical"
ports that are grouped to form one "logical" link, and in my case this
is reversed.

I've decided to make use of the new DPDK API "rte_eth_dev_owner_new/set"
(introduced by commit 5b7ba31148a8b and still marked as "experimental")
because this makes much easier for other applications (like VPP) to not
depend on the internals of given PMD - for example I did not have to
touch testpmd and l2fwd apps from DPDK to make them work since they were
already using/compatible with the new API.

This however requires some changes in VPP to make it work.  Previously
you simply assumed that DPDK port IDs start with 0 and assumed 1 to 1
correspondence between index in internal table with DPDK port id.  With
the use of some "internal/owned" DPDK ports this is no longer true so
what I am proposing is to add 'device_id' to 'dpdk_device_t' and make
use of it when passing to RTE functions and use 'RTE_ETH_FOREACH_DEV'
macro instead of plain 'for' loops starting with 0.

The patch in the attachment is what I have used for our customer.  Note
however that this was my first contact with VPP so there might be
something wrong with it or I might have missed some other places that
also need an update.  Also note that since the "ownership" API in DPDK
is still marked as experimental then you'll need to add
"-Wno-deprecated-declarations" to your compilation flags in platform
files (I'm using a separate one so don't have patch for you).

Let me know what you think.

Best regards
Andrzej
>From 0da5ba713a257f166ba4d8f111fa76ce757f4563 Mon Sep 17 00:00:00 2001
From: Andrzej Ostruszka 
Date: Fri, 6 Jul 2018 12:37:12 +0200
Subject: [PATCH] plugins: dpdk: do not use internal index for port id

Some DPDK ports can be used internally and not available to the user
application so one can not assume that index of internal structure is
DPDK port id.
---
 src/plugins/dpdk/device/cli.c   |  8 
 src/plugins/dpdk/device/common.c| 30 +++---
 src/plugins/dpdk/device/device.c| 16 
 src/plugins/dpdk/device/dpdk.h  |  3 ++-
 src/plugins/dpdk/device/dpdk_priv.h |  6 +++---
 src/plugins/dpdk/device/format.c| 22 +++---
 src/plugins/dpdk/device/init.c  | 22 +++---
 src/plugins/dpdk/device/node.c  |  2 +-
 src/plugins/dpdk/hqos/hqos.c| 10 +-
 10 files changed, 66 insertions(+), 65 deletions(-)

diff --git a/src/plugins/dpdk/device/cli.c b/src/plugins/dpdk/device/cli.c
index c9fcea5..0cdb344 100644
--- a/src/plugins/dpdk/device/cli.c
+++ b/src/plugins/dpdk/device/cli.c
@@ -60,7 +60,7 @@ get_hqos (u32 hw_if_index, u32 subport_id, dpdk_device_t ** xd,
   hw = vnet_get_hw_interface (dm->vnet_main, hw_if_index);
   *xd = vec_elt_at_index (dm->devices, hw->dev_instance);
 
-  rte_eth_dev_info_get ((*xd)->device_index, _info);
+  rte_eth_dev_info_get ((*xd)->device_id, _info);
   if (dev_info.pci_dev)
 {/* bonded interface has no pci info */
   vlib_pci_addr_t pci_addr;
@@ -1159,7 +1159,7 @@ set_dpdk_if_hqos_pktfield (vlib_main_t * vm, unformat_input_t * input,
   hw = vnet_get_hw_interface (dm->vnet_main, hw_if_index);
   xd = vec_elt_at_index (dm->devices, hw->dev_instance);
 
-  rte_eth_dev_info_get (xd->device_index, _info);
+  rte_eth_dev_info_get (xd->device_id, _info);
   if (dev_info.pci_dev)
 {/* bonded interface has no pci info */
   vlib_pci_addr_t pci_addr;
@@ -1350,7 +1350,7 @@ show_dpdk_if_hqos (vlib_main_t * vm, unformat_input_t * input,
   hw = vnet_get_hw_interface (dm->vnet_main, hw_if_index);
   xd = vec_elt_at_index (dm->devices, hw->dev_instance);
 
-  rte_eth_dev_info_get (xd->device_index, _info);
+