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 <a...@semihalf.com> 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] -=-=-=-=-=-=-=-=-=-=-=-
