* Re: [PATCH v2 0/4] provide man pages for binaries provided by DPDK
From: Thomas Monjalon @ 2016-10-26 21:32 UTC (permalink / raw)
To: christian.ehrhardt; +Cc: dev
In-Reply-To: <1473854336.8480.10.camel@brocade.com>
> > Christian Ehrhardt (4):
> > doc: move tool guides in their own subdirectory
> > doc: rendering and installation of man pages
> > doc: add basic invocation info for dpdk-pmdinfo
> > doc: add basic invocation info for dpdk-devbind
>
> Acked-by: Luca Boccassi <lboccass@brocade.com>
Applied with minor comments from John and me fixed, thanks
^ permalink raw reply
* Re: [PATCH v2] scripts: add more git log checks
From: Thomas Monjalon @ 2016-10-26 21:34 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <20160923124727.30356-1-ferruh.yigit@intel.com>
2016-09-23 13:47, Ferruh Yigit:
> Alphabetically sorted items to check and
> added git log capitalization checks for LRO, NIC and PMD
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v4 07/32] net/qede: fix 32 bit compilation
From: Thomas Monjalon @ 2016-10-26 21:40 UTC (permalink / raw)
To: Mody, Rasesh; +Cc: dev, Dept-EngDPDKDev, ferruh.yigit
In-Reply-To: <BLUPR0701MB15720701BD38B1C2B178C3639FAB0@BLUPR0701MB1572.namprd07.prod.outlook.com>
2016-10-26 21:01, Mody, Rasesh:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Wednesday, October 26, 2016 9:54 AM
> >
> > 2016-10-18 21:11, Rasesh Mody:
> > > Fix 32 bit compilation for gcc version 4.3.4.
> > >
> > > Fixes: ec94dbc57362 ("qede: add base driver")
> > >
> > > Signed-off-by: Rasesh Mody <rasesh.mody@qlogic.com>
> > [...]
> > > ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
> > > +ifeq ($(shell gcc -Wno-unused-but-set-variable -Werror -E - <
> > > +/dev/null > /dev/null 2>&1; echo $$?),0)
> > > CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
> > > +endif
> > > CFLAGS_BASE_DRIVER += -Wno-missing-declarations
> > > +ifeq ($(shell gcc -Wno-maybe-uninitialized -Werror -E - < /dev/null >
> > > +/dev/null 2>&1; echo $$?),0)
> > > CFLAGS_BASE_DRIVER += -Wno-maybe-uninitialized
> > > +endif
> > > CFLAGS_BASE_DRIVER += -Wno-strict-prototypes ifeq ($(shell test
> > > $(GCC_VERSION) -ge 60 && echo 1), 1) CFLAGS_BASE_DRIVER +=
> > > -Wno-shift-negative-value
> >
> > What the hell are you doing here?
>
> In one of our compilation testing on i586, we have gcc version 4.3.4. This version of gcc gives us following errors:
>
> cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
>
> -Wno-unused-but-set-variable option was added only in gcc version 5.1.0
> -Wno-maybe-uninitialized option was added only in gcc version 4.7.0
>
> All that above change does is that it checks if -Wno-unused-but-set-variable and -Wno-maybe-uninitialized options are available with gcc only then include them for compilation.
Have you tried to look what is done for other drivers?
It is using GCC_VERSION to check the compatibility.
> > 1/ You should better fix "unused-but-set-variable" errors 2/ It won't work
> > when cross-compiling because you do not use $(CC)
> > in $(shell gcc
>
> We tested on gcc version 6.2.0 on x86_64 without applying this patch. Errors related to "unused-but-set-variable" option were not seen. The only errors we saw are as noted above due to an older version of gcc.
> We do use $(shell gcc, however, it is used under ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y), so, I believe it should work when cross-compiling. For example, in one of our compilation testing on clang version 3.8.0, with this patch applied, we did not see any errors. Please let us know if you see otherwise.
Cross-compilation is using $(CROSS) prefix, e.g. when compiling for ARM on x86.
> However, I do agree it is better to use $(CC). We could change that with a follow on patch.
Please fix this patch by using GCC_VERSION.
^ permalink raw reply
* Re: [PATCH v4 18/32] net/qede: add missing 100G link speed capability
From: Thomas Monjalon @ 2016-10-26 21:43 UTC (permalink / raw)
To: Harish Patil; +Cc: dev, Dept-Eng DPDK Dev, ferruh.yigit
In-Reply-To: <D4366DC1.A5BF7%Harish.Patil@cavium.com>
2016-10-26 21:28, Harish Patil:
>
> >2016-10-18 21:11, Rasesh Mody:
> >> From: Harish Patil <harish.patil@qlogic.com>
> >>
> >> This patch fixes the missing 100G link speed advertisement
> >> when the 100G support was initially added.
> >>
> >> Fixes: 2af14ca79c0a ("net/qede: support 100G")
> >>
> >> Signed-off-by: Harish Patil <harish.patil@qlogic.com>
> >[...]
> >> [Features]
> >> +Speed capabilities = Y
> >
> >This feature should be checked only when it is fully implemented,
> >i.e. when you return the real capabilities of the device.
> >
> >> --- a/drivers/net/qede/qede_ethdev.c
> >> +++ b/drivers/net/qede/qede_ethdev.c
> >> @@ -599,7 +599,8 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
> >> DEV_TX_OFFLOAD_UDP_CKSUM |
> >> DEV_TX_OFFLOAD_TCP_CKSUM);
> >>
> >> - dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G;
> >> + dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G |
> >> + ETH_LINK_SPEED_100G;
> >> }
> >
> >It is only faking the capabilities at driver-level.
> >You should check if the underlying device is able to achieve 100G
> >before advertising this flag to the application.
> >
> >I suggest to update this patch to remove the doc update.
> >The contract is to fill it only when the code is fixed.
> >By the way, we must call every other drivers to properly implement
> >this feature.
> >
>
> Hi Thomas,
> Its not really a faking. The same driver supports all three link speeds.
> The required support for 100G was already present in the 16.07 inbox
> driver.
> We just had missed out advertising 100G link speed via
> dev_info->speed_capa.
> Hence it is - Fixes: 2af14ca79c0a ("net/qede: support 100G”).
> Hope it is okay.
Yes the code is okay. But it is not complete.
Please tell me you understand that you must fill speed_capa depending
of the device capabilities.
Then you will be able to fill "Speed capabilities" box in the doc.
^ permalink raw reply
* [dpdk-announce] release candidate 16.11-rc2
From: Thomas Monjalon @ 2016-10-26 22:09 UTC (permalink / raw)
To: announce
A new DPDK release candidate is ready for testing:
http://dpdk.org/browse/dpdk/tag/?id=v16.11-rc2
The release 16.11 is going to be small.
We should try to speed up testing and fixing bugs in order to start
the next cycle timely.
Please shout if you are aware of an important bug.
Now, priorities are:
- bug fixing
- API names check (renaming is still accepted)
- documentation and release notes
Thank you everyone
^ permalink raw reply
* Re: [PATCH v2] eal: fix libabi macro for device generalization patches
From: Shreyansh Jain @ 2016-10-27 5:06 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, thomas.monjalon
In-Reply-To: <275ffc52-acb0-c177-da32-fb8c3fee497a@intel.com>
Hello Ferruh,
On Wednesday 26 October 2016 07:55 PM, Ferruh Yigit wrote:
> Hi Shreyansh,
>
> On 10/26/2016 2:12 PM, Shreyansh Jain wrote:
>> On Wednesday 26 October 2016 06:30 PM, Shreyansh Jain wrote:
>>> rte_device/driver generalization patches [1] were merged without a change
>>> in the LIBABIVER macro. This patches bumps the macro of affected libs.
>>>
>>> Also, deprecation notice from 16.07 has been removed and release notes for
>>> 16.11 added.
>>>
>>> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
>>> --
>>> v2:
>>> - Mark bumped libraries in release_16_11.rst file
>>> - change code symbol names from text to code layout
>>>
>>> ---
>
> <...>
>
>>> .. code-block:: diff
>>>
>>> - libethdev.so.4
>>> + + libethdev.so.4
>>
>> Just noticed:
>> Should the '4' here reflect the current LIBABIVER number?
>> If so, I will send this patch again.
>
> Yes, as you guessed, it should be:
> - libethdev.so.4
> + + libethdev.so.5
>
> <...>
>
>>> diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile
>>> index a15b762..122798c 100644
>>> --- a/lib/librte_eal/bsdapp/eal/Makefile
>>> +++ b/lib/librte_eal/bsdapp/eal/Makefile
>>> @@ -48,7 +48,7 @@ LDLIBS += -lgcc_s
>>>
>>> EXPORT_MAP := rte_eal_version.map
>>>
>>> -LIBABIVER := 3
>>> +LIBABIVER := 4
>
> eal version seems already increased for this release, 2 => 3, in:
> d7e61ad3ae36 ("log: remove deprecated history dump")
>
> So NO need to increase it again, sorry for late notice, I just
> recognized it.
> Only librte_ether and librte_cryptodev requires the increase.
Thanks for clearing this.
I will bump librte_ether and librte_cryptodev and send across v3.
>
> <...>
>
> Thanks,
> ferruh
>
>
The LIBABI check script is really helpful. I wish I had run that for
rte_driver/device patchset. Thanks for that info, though.
-
Shreyansh
^ permalink raw reply
* Re: [PATCH v2] eal: fix libabi macro for device generalization patches
From: Shreyansh Jain @ 2016-10-27 5:07 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ferruh Yigit
In-Reply-To: <2105472.0JeDs3sFAP@xps13>
On Wednesday 26 October 2016 08:53 PM, Thomas Monjalon wrote:
> 2016-10-26 15:25, Ferruh Yigit:
>> eal version seems already increased for this release, 2 => 3, in:
>> d7e61ad3ae36 ("log: remove deprecated history dump")
>
> Yes thanks.
>
>> So NO need to increase it again, sorry for late notice, I just
>> recognized it.
>> Only librte_ether and librte_cryptodev requires the increase.
>
> Please could you also explain in the commit message that:
> - EAL was already bumped
> - what is the breakage in ethdev
> - what is the breakage in cryptodev
Indeed. Will do in v3
>
> Thanks
>
-
Shreyansh
^ permalink raw reply
* [PATCH] doc: remove Intel reference from multi-process support guide
From: Jerin Jacob @ 2016-10-27 6:11 UTC (permalink / raw)
To: dev; +Cc: thomas.monjalon
multi-process support has been verified on non IA such as ARMv8.
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index badd102..2a996ae 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -35,7 +35,7 @@ Multi-process Support
In the DPDK, multi-process support is designed to allow a group of DPDK processes
to work together in a simple transparent manner to perform packet processing,
-or other workloads, on Intel® architecture hardware.
+or other workloads.
To support this functionality,
a number of additions have been made to the core DPDK Environment Abstraction Layer (EAL).
--
2.5.5
^ permalink raw reply related
* Solarflare PMD submission question
From: Andrew Rybchenko @ 2016-10-27 6:34 UTC (permalink / raw)
To: dev
Hi,
we would like to include Solarflare libefx-based PMD in the DPDK 17.02
and start the upstreaming process.
The driver supports Solarflare SFN7xxx and SFN8xxx families of 10/40
Gbps adapters.
The driver has base driver. It is just fresh version of the same code
which is used in the FreeBSD [1], illumos [2] and some other Solarflare
drivers.
The question is how to submit the base driver which is pretty big. Mail
size of the patch which imports it is about 2 Mb.
Further changes in the base driver will go in small patches (as it is
done, for example, in the FreeBSD).
The PMD itself is split into small and, I hope, readable and nice patches.
[1] https://svnweb.freebsd.org/base/head/sys/dev/sfxge/common/
[2]
https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/io/sfxge/common/
Andrew.
^ permalink raw reply
* [PATCH v3] eal: fix libabi macro for device generalization patches
From: Shreyansh Jain @ 2016-10-27 7:08 UTC (permalink / raw)
To: thomas.monjalon; +Cc: dev, Shreyansh Jain, ferruh.yigit
In-Reply-To: <1477486817-1284-1-git-send-email-shreyansh.jain@nxp.com>
rte_device/driver generalization patches [1] were merged without a change
in the LIBABIVER macro. This patches bumps the macro of affected libs.
(librte_eal was already bumped; libcryptodev and libetherdev have been
bumped).
Details of ABI/API changes:
- EAL (version not bumped)
|- type field was removed from rte_driver
|- rte_pci_device now embeds rte_device
|- rte_pci_resource renamed to rte_mem_resource
|- numa_node and devargs of rte_pci_driver is moved to rte_driver
|- APIs for device hotplug (attach/detach) moved into EAL
|- API rte_eal_pci_device_name added for PCI device naming
|- vdev registration API introduced (rte_eal_vdrv_register,
| rte_eal_vdrv_unregister
- librte_crypto (v 1=>2)
|- removed rte_cryptodev_create_unique_device_name API
|- moved device naming to EAL
- librte_ethdev (v 4=>5)
|- rte_eth_dev_type is removed
|- removed dev_type from rte_eth_dev_allocate API
|- removed API rte_eth_dev_get_device_type
|- removed API rte_eth_dev_get_addr_by_port
|- removed API rte_eth_dev_get_port_by_addr
|- removed rte_cryptodev_create_unique_device_name API
|- moved device naming to EAL
Also, deprecation notice from 16.07 has been removed and release notes for
16.11 added.
[1] http://dpdk.org/ml/archives/dev/2016-September/047087.html
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
--
v3:
- add API/ABI change info in commit log
- fix library version change notification in release note
- fix erroneous change to librte_eal version in v2
---
doc/guides/rel_notes/deprecation.rst | 12 ------------
doc/guides/rel_notes/release_16_11.rst | 30 ++++++++++++++++++++++++++++--
lib/librte_cryptodev/Makefile | 2 +-
lib/librte_ether/Makefile | 2 +-
4 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index d5c1490..884a231 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -18,18 +18,6 @@ Deprecation Notices
``nb_seg_max`` and ``nb_mtu_seg_max`` providing information about number of
segments limit to be transmitted by device for TSO/non-TSO packets.
-* The ethdev hotplug API is going to be moved to EAL with a notification
- mechanism added to crypto and ethdev libraries so that hotplug is now
- available to both of them. This API will be stripped of the device arguments
- so that it only cares about hotplugging.
-
-* Structures embodying pci and vdev devices are going to be reworked to
- integrate new common rte_device / rte_driver objects (see
- http://dpdk.org/ml/archives/dev/2016-January/031390.html).
- ethdev and crypto libraries will then only handle those objects so that they
- do not need to care about the kind of devices that are being used, making it
- easier to add new buses later.
-
* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some fields
may be reordered to facilitate the writing of ``data_off``, ``refcnt``, and
``nb_segs`` in one operation, because some platforms have an overhead if the
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index aa0c09a..5a5485b 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -149,6 +149,32 @@ Resolved Issues
EAL
~~~
+* **Improved device/driver heirarchy and generalized hotplugging**
+
+ Device and driver relationship has been restructured by introducing generic
+ classes. This paves way for having PCI, VDEV and other device types as
+ just instantiated objects rather than classes in themselves. Hotplugging too
+ has been generalized into EAL so that ethernet or crypto devices can use the
+ common infrastructure.
+
+ * removed ``pmd_type`` as way of segragation of devices
+ * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
+ ``rte_pci_driver``. These can now be used by any instantiated object of
+ ``rte_driver``.
+ * added ``rte_device`` class and all PCI and VDEV devices inherit from it
+ * renamed devinit/devuninit handlers to probe/remove to make it more
+ semantically correct with respect to device<=>driver relationship
+ * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
+ APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
+ * helpers and support macros have been renamed to make them more synonymous
+ with their device types
+ (e.g. ``PMD_REGISTER_DRIVER`` => ``DRIVER_REGISTER_PCI``)
+ * Device naming functions have been generalized from ethdev and cryptodev
+ to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
+ unique device name from PCI Domain-BDF description.
+ * Virtual device registration APIs have been added: ``rte_eal_vdrv_register``
+ and ``rte_eal_vdrv_unregister``.
+
Drivers
~~~~~~~
@@ -232,11 +258,11 @@ The libraries prepended with a plus sign were incremented in this version.
.. code-block:: diff
- libethdev.so.4
+ + libethdev.so.5
librte_acl.so.2
librte_cfgfile.so.2
librte_cmdline.so.2
- librte_cryptodev.so.1
+ + librte_cryptodev.so.2
librte_distributor.so.1
+ librte_eal.so.3
librte_hash.so.2
diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cryptodev/Makefile
index 314a046..aebf5d9 100644
--- a/lib/librte_cryptodev/Makefile
+++ b/lib/librte_cryptodev/Makefile
@@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_cryptodev.a
# library version
-LIBABIVER := 1
+LIBABIVER := 2
# build flags
CFLAGS += -O3
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index 488b7c8..bc2e5f6 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
EXPORT_MAP := rte_ether_version.map
-LIBABIVER := 4
+LIBABIVER := 5
SRCS-y += rte_ethdev.c
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Wang, Zhihong @ 2016-10-27 9:00 UTC (permalink / raw)
To: Maxime Coquelin, Yuanhan Liu, stephen@networkplumber.org,
Pierre Pfister (ppfister)
Cc: dev@dpdk.org, vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <db6244b6-37ed-e26e-3c93-420818efa8ae@redhat.com>
Hi Maxime,
Seems indirect desc feature is causing serious performance
degradation on Haswell platform, about 20% drop for both
mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
both iofwd and macfwd.
I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz.
Could you please verify if this is true in your test?
Thanks
Zhihong
> -----Original Message-----
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Monday, October 17, 2016 10:15 PM
> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> Cc: Wang, Zhihong <zhihong.wang@intel.com>; Xie, Huawei
> <huawei.xie@intel.com>; dev@dpdk.org; vkaplans@redhat.com;
> mst@redhat.com; stephen@networkplumber.org
> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support
> to the TX path
>
>
>
> On 10/17/2016 03:21 PM, Yuanhan Liu wrote:
> > On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
> >>> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
> >>> I'll continue the investigation early next week.
> >>
> >> The root cause is identified.
> >> When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
> >> for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
> >> virtio-net kernel driver) use indirect only for Tx.
> >> I'll implement indirect support for the Rx path in vhost lib, but the
> >> change will be too big for -rc release.
> >> I propose in the mean time to disable INDIRECT_DESC feature in vhost
> >> lib, we can still enable it locally for testing.
> >>
> >> Yuanhan, is it ok for you?
> >
> > That's okay.
> I'll send a patch to disable it then.
>
> >
> >>
> >>> Has anyone already tested Windows guest with vhost-net, which also
> has
> >>> indirect descs support?
> >>
> >> I tested and confirm it works with vhost-net.
> >
> > I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
> > for Rx path, right?
>
> No, it does support it actually.
> I thought it didn't support too, I misread the Kernel implementation of
> vhost-net and virtio-net. Acutally, virtio-net makes use of indirect
> in Rx path when mergeable buffers is disabled.
>
> The confusion certainly comes from me, sorry about that.
>
> Maxime
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Maxime Coquelin @ 2016-10-27 9:10 UTC (permalink / raw)
To: Wang, Zhihong, Yuanhan Liu, stephen@networkplumber.org,
Pierre Pfister (ppfister)
Cc: dev@dpdk.org, vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <8F6C2BD409508844A0EFC19955BE09414E7D8BDF@SHSMSX103.ccr.corp.intel.com>
Hi Zhihong,
On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
> Hi Maxime,
>
> Seems indirect desc feature is causing serious performance
> degradation on Haswell platform, about 20% drop for both
> mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
> both iofwd and macfwd.
I tested PVP (with macswap on guest) and Txonly/Rxonly on an Ivy Bridge
platform, and didn't faced such a drop.
Have you tried to pass indirect_desc=off to qemu cmdline to see if you
recover the performance?
Yuanhan, which platform did you use when you tested it with zero copy?
>
> I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz.
>
> Could you please verify if this is true in your test?
I'll try -rc1/-rc2 on my platform, and let you know.
Thanks,
Maxime
>
>
> Thanks
> Zhihong
>
>> -----Original Message-----
>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>> Sent: Monday, October 17, 2016 10:15 PM
>> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; Xie, Huawei
>> <huawei.xie@intel.com>; dev@dpdk.org; vkaplans@redhat.com;
>> mst@redhat.com; stephen@networkplumber.org
>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support
>> to the TX path
>>
>>
>>
>> On 10/17/2016 03:21 PM, Yuanhan Liu wrote:
>>> On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
>>>>> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
>>>>> I'll continue the investigation early next week.
>>>>
>>>> The root cause is identified.
>>>> When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
>>>> for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
>>>> virtio-net kernel driver) use indirect only for Tx.
>>>> I'll implement indirect support for the Rx path in vhost lib, but the
>>>> change will be too big for -rc release.
>>>> I propose in the mean time to disable INDIRECT_DESC feature in vhost
>>>> lib, we can still enable it locally for testing.
>>>>
>>>> Yuanhan, is it ok for you?
>>>
>>> That's okay.
>> I'll send a patch to disable it then.
>>
>>>
>>>>
>>>>> Has anyone already tested Windows guest with vhost-net, which also
>> has
>>>>> indirect descs support?
>>>>
>>>> I tested and confirm it works with vhost-net.
>>>
>>> I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
>>> for Rx path, right?
>>
>> No, it does support it actually.
>> I thought it didn't support too, I misread the Kernel implementation of
>> vhost-net and virtio-net. Acutally, virtio-net makes use of indirect
>> in Rx path when mergeable buffers is disabled.
>>
>> The confusion certainly comes from me, sorry about that.
>>
>> Maxime
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Maxime Coquelin @ 2016-10-27 9:55 UTC (permalink / raw)
To: Wang, Zhihong, Yuanhan Liu, stephen@networkplumber.org,
Pierre Pfister (ppfister)
Cc: dev@dpdk.org, vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <a7ea1206-86ab-911c-a6b4-718e4dd5c1f2@redhat.com>
On 10/27/2016 11:10 AM, Maxime Coquelin wrote:
> Hi Zhihong,
>
> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
>> Hi Maxime,
>>
>> Seems indirect desc feature is causing serious performance
>> degradation on Haswell platform, about 20% drop for both
>> mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
>> both iofwd and macfwd.
> I tested PVP (with macswap on guest) and Txonly/Rxonly on an Ivy Bridge
> platform, and didn't faced such a drop.
> Have you tried to pass indirect_desc=off to qemu cmdline to see if you
> recover the performance?
>
> Yuanhan, which platform did you use when you tested it with zero copy?
>
>>
>> I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz.
>>
>> Could you please verify if this is true in your test?
> I'll try -rc1/-rc2 on my platform, and let you know.
As a first test, I tried again Txonly from the guest to the host (Rxonly),
where Tx indirect descriptors are used, on my E5-2665 @2.40GHz:
v16.11-rc1: 10.81Mpps
v16.11-rc2: 10.91Mpps
-rc2 is even slightly better in my case.
Could you please run the same test on your platform?
And could you provide me more info on your fwd bench?
Do you use dpdk-pktgen on host, or you do fwd on howt with a real NIC
also?
Thanks,
Maxime
> Thanks,
> Maxime
>
>>
>>
>> Thanks
>> Zhihong
>>
>>> -----Original Message-----
>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>>> Sent: Monday, October 17, 2016 10:15 PM
>>> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
>>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; Xie, Huawei
>>> <huawei.xie@intel.com>; dev@dpdk.org; vkaplans@redhat.com;
>>> mst@redhat.com; stephen@networkplumber.org
>>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors
>>> support
>>> to the TX path
>>>
>>>
>>>
>>> On 10/17/2016 03:21 PM, Yuanhan Liu wrote:
>>>> On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
>>>>>> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
>>>>>> I'll continue the investigation early next week.
>>>>>
>>>>> The root cause is identified.
>>>>> When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
>>>>> for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
>>>>> virtio-net kernel driver) use indirect only for Tx.
>>>>> I'll implement indirect support for the Rx path in vhost lib, but the
>>>>> change will be too big for -rc release.
>>>>> I propose in the mean time to disable INDIRECT_DESC feature in vhost
>>>>> lib, we can still enable it locally for testing.
>>>>>
>>>>> Yuanhan, is it ok for you?
>>>>
>>>> That's okay.
>>> I'll send a patch to disable it then.
>>>
>>>>
>>>>>
>>>>>> Has anyone already tested Windows guest with vhost-net, which also
>>> has
>>>>>> indirect descs support?
>>>>>
>>>>> I tested and confirm it works with vhost-net.
>>>>
>>>> I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
>>>> for Rx path, right?
>>>
>>> No, it does support it actually.
>>> I thought it didn't support too, I misread the Kernel implementation of
>>> vhost-net and virtio-net. Acutally, virtio-net makes use of indirect
>>> in Rx path when mergeable buffers is disabled.
>>>
>>> The confusion certainly comes from me, sorry about that.
>>>
>>> Maxime
^ permalink raw reply
* Re: [PATCH v3] eal: fix libabi macro for device generalization patches
From: Thomas Monjalon @ 2016-10-27 10:15 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: dev, ferruh.yigit
In-Reply-To: <1477552109-18624-1-git-send-email-shreyansh.jain@nxp.com>
2016-10-27 12:38, Shreyansh Jain:
> rte_device/driver generalization patches [1] were merged without a change
> in the LIBABIVER macro. This patches bumps the macro of affected libs.
It is not a macro but a Makefile variable.
> (librte_eal was already bumped; libcryptodev and libetherdev have been
> bumped).
Please provide the commit id where EAL was bumped.
> Details of ABI/API changes:
> - EAL (version not bumped)
not bumped -> already bumped
> |- type field was removed from rte_driver
> |- rte_pci_device now embeds rte_device
> |- rte_pci_resource renamed to rte_mem_resource
> |- numa_node and devargs of rte_pci_driver is moved to rte_driver
> |- APIs for device hotplug (attach/detach) moved into EAL
> |- API rte_eal_pci_device_name added for PCI device naming
> |- vdev registration API introduced (rte_eal_vdrv_register,
> | rte_eal_vdrv_unregister
>
> - librte_crypto (v 1=>2)
> |- removed rte_cryptodev_create_unique_device_name API
> |- moved device naming to EAL
>
> - librte_ethdev (v 4=>5)
> |- rte_eth_dev_type is removed
> |- removed dev_type from rte_eth_dev_allocate API
> |- removed API rte_eth_dev_get_device_type
> |- removed API rte_eth_dev_get_addr_by_port
> |- removed API rte_eth_dev_get_port_by_addr
> |- removed rte_cryptodev_create_unique_device_name API
> |- moved device naming to EAL
>
> Also, deprecation notice from 16.07 has been removed and release notes for
> 16.11 added.
>
> [1] http://dpdk.org/ml/archives/dev/2016-September/047087.html
>
> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
[...]
> --- a/doc/guides/rel_notes/release_16_11.rst
> +++ b/doc/guides/rel_notes/release_16_11.rst
> @@ -149,6 +149,32 @@ Resolved Issues
It is the "Resolved Issues" section.
Please move in the "API Changes" section.
> EAL
> ~~~
>
> +* **Improved device/driver heirarchy and generalized hotplugging**
typo: hierarchy
> + Device and driver relationship has been restructured by introducing generic
> + classes. This paves way for having PCI, VDEV and other device types as
> + just instantiated objects rather than classes in themselves. Hotplugging too
> + has been generalized into EAL so that ethernet or crypto devices can use the
> + common infrastructure.
> +
> + * removed ``pmd_type`` as way of segragation of devices
> + * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
> + ``rte_pci_driver``. These can now be used by any instantiated object of
> + ``rte_driver``.
> + * added ``rte_device`` class and all PCI and VDEV devices inherit from it
> + * renamed devinit/devuninit handlers to probe/remove to make it more
> + semantically correct with respect to device<=>driver relationship
> + * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
> + APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
> + * helpers and support macros have been renamed to make them more synonymous
> + with their device types
> + (e.g. ``PMD_REGISTER_DRIVER`` => ``DRIVER_REGISTER_PCI``)
It is RTE_PMD_REGISTER_PCI
> + * Device naming functions have been generalized from ethdev and cryptodev
> + to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
> + unique device name from PCI Domain-BDF description.
> + * Virtual device registration APIs have been added: ``rte_eal_vdrv_register``
> + and ``rte_eal_vdrv_unregister``.
Thanks
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Wang, Zhihong @ 2016-10-27 10:19 UTC (permalink / raw)
To: Maxime Coquelin, Yuanhan Liu, stephen@networkplumber.org,
Pierre Pfister (ppfister)
Cc: dev@dpdk.org, vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <7a987be6-feec-0639-211a-462cf2b44514@redhat.com>
> -----Original Message-----
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Thursday, October 27, 2016 5:55 PM
> To: Wang, Zhihong <zhihong.wang@intel.com>; Yuanhan Liu
> <yuanhan.liu@linux.intel.com>; stephen@networkplumber.org; Pierre
> Pfister (ppfister) <ppfister@cisco.com>
> Cc: Xie, Huawei <huawei.xie@intel.com>; dev@dpdk.org;
> vkaplans@redhat.com; mst@redhat.com
> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support
> to the TX path
>
>
>
> On 10/27/2016 11:10 AM, Maxime Coquelin wrote:
> > Hi Zhihong,
> >
> > On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
> >> Hi Maxime,
> >>
> >> Seems indirect desc feature is causing serious performance
> >> degradation on Haswell platform, about 20% drop for both
> >> mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
> >> both iofwd and macfwd.
> > I tested PVP (with macswap on guest) and Txonly/Rxonly on an Ivy Bridge
> > platform, and didn't faced such a drop.
> > Have you tried to pass indirect_desc=off to qemu cmdline to see if you
> > recover the performance?
> >
> > Yuanhan, which platform did you use when you tested it with zero copy?
> >
> >>
> >> I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz.
> >>
> >> Could you please verify if this is true in your test?
> > I'll try -rc1/-rc2 on my platform, and let you know.
> As a first test, I tried again Txonly from the guest to the host (Rxonly),
> where Tx indirect descriptors are used, on my E5-2665 @2.40GHz:
> v16.11-rc1: 10.81Mpps
> v16.11-rc2: 10.91Mpps
>
> -rc2 is even slightly better in my case.
> Could you please run the same test on your platform?
I mean to use rc2 as both host and guest, and compare the
perf between indirect=0 and indirect=1.
I use PVP traffic, tried both testpmd and OvS as the forwarding
engine in host, and testpmd in guest.
Thanks
Zhihong
>
> And could you provide me more info on your fwd bench?
> Do you use dpdk-pktgen on host, or you do fwd on howt with a real NIC
> also?
>
> Thanks,
> Maxime
> > Thanks,
> > Maxime
> >
> >>
> >>
> >> Thanks
> >> Zhihong
> >>
> >>> -----Original Message-----
> >>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> >>> Sent: Monday, October 17, 2016 10:15 PM
> >>> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> >>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; Xie, Huawei
> >>> <huawei.xie@intel.com>; dev@dpdk.org; vkaplans@redhat.com;
> >>> mst@redhat.com; stephen@networkplumber.org
> >>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors
> >>> support
> >>> to the TX path
> >>>
> >>>
> >>>
> >>> On 10/17/2016 03:21 PM, Yuanhan Liu wrote:
> >>>> On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
> >>>>>> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
> >>>>>> I'll continue the investigation early next week.
> >>>>>
> >>>>> The root cause is identified.
> >>>>> When INDIRECT_DESC feature is negotiated, Windows guest uses
> indirect
> >>>>> for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
> >>>>> virtio-net kernel driver) use indirect only for Tx.
> >>>>> I'll implement indirect support for the Rx path in vhost lib, but the
> >>>>> change will be too big for -rc release.
> >>>>> I propose in the mean time to disable INDIRECT_DESC feature in vhost
> >>>>> lib, we can still enable it locally for testing.
> >>>>>
> >>>>> Yuanhan, is it ok for you?
> >>>>
> >>>> That's okay.
> >>> I'll send a patch to disable it then.
> >>>
> >>>>
> >>>>>
> >>>>>> Has anyone already tested Windows guest with vhost-net, which
> also
> >>> has
> >>>>>> indirect descs support?
> >>>>>
> >>>>> I tested and confirm it works with vhost-net.
> >>>>
> >>>> I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
> >>>> for Rx path, right?
> >>>
> >>> No, it does support it actually.
> >>> I thought it didn't support too, I misread the Kernel implementation of
> >>> vhost-net and virtio-net. Acutally, virtio-net makes use of indirect
> >>> in Rx path when mergeable buffers is disabled.
> >>>
> >>> The confusion certainly comes from me, sorry about that.
> >>>
> >>> Maxime
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Yuanhan Liu @ 2016-10-27 10:33 UTC (permalink / raw)
To: Maxime Coquelin; +Cc: mst@redhat.com, dev@dpdk.org, vkaplans@redhat.com
In-Reply-To: <a7ea1206-86ab-911c-a6b4-718e4dd5c1f2@redhat.com>
On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin wrote:
> Hi Zhihong,
>
> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
> >Hi Maxime,
> >
> >Seems indirect desc feature is causing serious performance
> >degradation on Haswell platform, about 20% drop for both
> >mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
> >both iofwd and macfwd.
> I tested PVP (with macswap on guest) and Txonly/Rxonly on an Ivy Bridge
> platform, and didn't faced such a drop.
I was actually wondering that may be the cause. I tested it with
my IvyBridge server as well, I saw no drop.
Maybe you should find a similar platform (Haswell) and have a try?
--yliu
> Have you tried to pass indirect_desc=off to qemu cmdline to see if you
> recover the performance?
>
> Yuanhan, which platform did you use when you tested it with zero copy?
>
> >
> >I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz.
> >
> >Could you please verify if this is true in your test?
> I'll try -rc1/-rc2 on my platform, and let you know.
>
> Thanks,
> Maxime
>
> >
> >
> >Thanks
> >Zhihong
> >
> >>-----Original Message-----
> >>From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> >>Sent: Monday, October 17, 2016 10:15 PM
> >>To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> >>Cc: Wang, Zhihong <zhihong.wang@intel.com>; Xie, Huawei
> >><huawei.xie@intel.com>; dev@dpdk.org; vkaplans@redhat.com;
> >>mst@redhat.com; stephen@networkplumber.org
> >>Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support
> >>to the TX path
> >>
> >>
> >>
> >>On 10/17/2016 03:21 PM, Yuanhan Liu wrote:
> >>>On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
> >>>>>On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
> >>>>>I'll continue the investigation early next week.
> >>>>
> >>>>The root cause is identified.
> >>>>When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
> >>>>for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
> >>>>virtio-net kernel driver) use indirect only for Tx.
> >>>>I'll implement indirect support for the Rx path in vhost lib, but the
> >>>>change will be too big for -rc release.
> >>>>I propose in the mean time to disable INDIRECT_DESC feature in vhost
> >>>>lib, we can still enable it locally for testing.
> >>>>
> >>>>Yuanhan, is it ok for you?
> >>>
> >>>That's okay.
> >>I'll send a patch to disable it then.
> >>
> >>>
> >>>>
> >>>>>Has anyone already tested Windows guest with vhost-net, which also
> >>has
> >>>>>indirect descs support?
> >>>>
> >>>>I tested and confirm it works with vhost-net.
> >>>
> >>>I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
> >>>for Rx path, right?
> >>
> >>No, it does support it actually.
> >>I thought it didn't support too, I misread the Kernel implementation of
> >>vhost-net and virtio-net. Acutally, virtio-net makes use of indirect
> >>in Rx path when mergeable buffers is disabled.
> >>
> >>The confusion certainly comes from me, sorry about that.
> >>
> >>Maxime
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Maxime Coquelin @ 2016-10-27 10:35 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: mst@redhat.com, dev@dpdk.org, vkaplans@redhat.com
In-Reply-To: <20161027103317.GM16751@yliu-dev.sh.intel.com>
On 10/27/2016 12:33 PM, Yuanhan Liu wrote:
> On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin wrote:
>> Hi Zhihong,
>>
>> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
>>> Hi Maxime,
>>>
>>> Seems indirect desc feature is causing serious performance
>>> degradation on Haswell platform, about 20% drop for both
>>> mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
>>> both iofwd and macfwd.
>> I tested PVP (with macswap on guest) and Txonly/Rxonly on an Ivy Bridge
>> platform, and didn't faced such a drop.
>
> I was actually wondering that may be the cause. I tested it with
> my IvyBridge server as well, I saw no drop.
>
> Maybe you should find a similar platform (Haswell) and have a try?
Yes, that's why I asked Zhihong whether he could test Txonly in guest to
see if issue is reproducible like this.
I will be easier for me to find an Haswell machine if it has not to be
connected back to back to and HW/SW packet generator.
Thanks,
Maxime
>
> --yliu
>
>> Have you tried to pass indirect_desc=off to qemu cmdline to see if you
>> recover the performance?
>>
>> Yuanhan, which platform did you use when you tested it with zero copy?
>>
>>>
>>> I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz.
>>>
>>> Could you please verify if this is true in your test?
>> I'll try -rc1/-rc2 on my platform, and let you know.
>>
>> Thanks,
>> Maxime
>>
>>>
>>>
>>> Thanks
>>> Zhihong
>>>
>>>> -----Original Message-----
>>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>>>> Sent: Monday, October 17, 2016 10:15 PM
>>>> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
>>>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; Xie, Huawei
>>>> <huawei.xie@intel.com>; dev@dpdk.org; vkaplans@redhat.com;
>>>> mst@redhat.com; stephen@networkplumber.org
>>>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support
>>>> to the TX path
>>>>
>>>>
>>>>
>>>> On 10/17/2016 03:21 PM, Yuanhan Liu wrote:
>>>>> On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
>>>>>>> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
>>>>>>> I'll continue the investigation early next week.
>>>>>>
>>>>>> The root cause is identified.
>>>>>> When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
>>>>>> for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
>>>>>> virtio-net kernel driver) use indirect only for Tx.
>>>>>> I'll implement indirect support for the Rx path in vhost lib, but the
>>>>>> change will be too big for -rc release.
>>>>>> I propose in the mean time to disable INDIRECT_DESC feature in vhost
>>>>>> lib, we can still enable it locally for testing.
>>>>>>
>>>>>> Yuanhan, is it ok for you?
>>>>>
>>>>> That's okay.
>>>> I'll send a patch to disable it then.
>>>>
>>>>>
>>>>>>
>>>>>>> Has anyone already tested Windows guest with vhost-net, which also
>>>> has
>>>>>>> indirect descs support?
>>>>>>
>>>>>> I tested and confirm it works with vhost-net.
>>>>>
>>>>> I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
>>>>> for Rx path, right?
>>>>
>>>> No, it does support it actually.
>>>> I thought it didn't support too, I misread the Kernel implementation of
>>>> vhost-net and virtio-net. Acutally, virtio-net makes use of indirect
>>>> in Rx path when mergeable buffers is disabled.
>>>>
>>>> The confusion certainly comes from me, sorry about that.
>>>>
>>>> Maxime
^ permalink raw reply
* Re: Solarflare PMD submission question
From: Thomas Monjalon @ 2016-10-27 10:37 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev
In-Reply-To: <d0f0fa30-975f-8cce-7074-125f6190e908@solarflare.com>
Hi,
First of all, welcome to DPDK!
2016-10-27 09:34, Andrew Rybchenko:
> Hi,
>
> we would like to include Solarflare libefx-based PMD in the DPDK 17.02
> and start the upstreaming process.
> The driver supports Solarflare SFN7xxx and SFN8xxx families of 10/40
> Gbps adapters.
> The driver has base driver. It is just fresh version of the same code
> which is used in the FreeBSD [1], illumos [2] and some other Solarflare
> drivers.
Unfortunately it is common to have some big base drivers in DPDK.
Note that some PMD rely on their kernel counterpart for the control path.
It is a way to avoid code duplication.
As far as I understand, it is easier to share queues with DPDK from kernel
when the device supports an IOMMU.
> The question is how to submit the base driver which is pretty big. Mail
> size of the patch which imports it is about 2 Mb.
First answer is a question:
Have you thought about cooperating with the kernel driver for your PMD?
If you really cannot use this approach, then we have to maintain this
whole base driver in DPDK.
It will be easier to read, understand and reference if it is a bit split.
Could you try to send it as 10 to 20 patches explaining the role of each
part and giving some design details?
It would be also really appreciated to provide a design documentation
in doc/guides/nics. Are the datasheets open? A link in the doc would help.
> Further changes in the base driver will go in small patches (as it is
> done, for example, in the FreeBSD).
> The PMD itself is split into small and, I hope, readable and nice patches.
Good to know. Thanks
Please be prepare to work on several iterations of the patch series.
PS: the mailing list put emails exceeding 300KB into a moderation queue.
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Yuanhan Liu @ 2016-10-27 10:46 UTC (permalink / raw)
To: Maxime Coquelin; +Cc: mst@redhat.com, dev@dpdk.org, vkaplans@redhat.com
In-Reply-To: <0ba8f8c9-2174-b3c1-4f07-f6911bffa6cd@redhat.com>
On Thu, Oct 27, 2016 at 12:35:11PM +0200, Maxime Coquelin wrote:
>
>
> On 10/27/2016 12:33 PM, Yuanhan Liu wrote:
> >On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin wrote:
> >>Hi Zhihong,
> >>
> >>On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
> >>>Hi Maxime,
> >>>
> >>>Seems indirect desc feature is causing serious performance
> >>>degradation on Haswell platform, about 20% drop for both
> >>>mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
> >>>both iofwd and macfwd.
> >>I tested PVP (with macswap on guest) and Txonly/Rxonly on an Ivy Bridge
> >>platform, and didn't faced such a drop.
> >
> >I was actually wondering that may be the cause. I tested it with
> >my IvyBridge server as well, I saw no drop.
> >
> >Maybe you should find a similar platform (Haswell) and have a try?
> Yes, that's why I asked Zhihong whether he could test Txonly in guest to
> see if issue is reproducible like this.
I have no Haswell box, otherwise I could do a quick test for you. IIRC,
he tried to disable the indirect_desc feature, then the performance
recovered. So, it's likely the indirect_desc is the culprit here.
> I will be easier for me to find an Haswell machine if it has not to be
> connected back to back to and HW/SW packet generator.
Makes sense.
--yliu
>
> Thanks,
> Maxime
>
> >
> > --yliu
> >
> >>Have you tried to pass indirect_desc=off to qemu cmdline to see if you
> >>recover the performance?
> >>
> >>Yuanhan, which platform did you use when you tested it with zero copy?
> >>
> >>>
> >>>I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz.
> >>>
> >>>Could you please verify if this is true in your test?
> >>I'll try -rc1/-rc2 on my platform, and let you know.
> >>
> >>Thanks,
> >>Maxime
> >>
> >>>
> >>>
> >>>Thanks
> >>>Zhihong
> >>>
> >>>>-----Original Message-----
> >>>>From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> >>>>Sent: Monday, October 17, 2016 10:15 PM
> >>>>To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> >>>>Cc: Wang, Zhihong <zhihong.wang@intel.com>; Xie, Huawei
> >>>><huawei.xie@intel.com>; dev@dpdk.org; vkaplans@redhat.com;
> >>>>mst@redhat.com; stephen@networkplumber.org
> >>>>Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support
> >>>>to the TX path
> >>>>
> >>>>
> >>>>
> >>>>On 10/17/2016 03:21 PM, Yuanhan Liu wrote:
> >>>>>On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
> >>>>>>>On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
> >>>>>>>I'll continue the investigation early next week.
> >>>>>>
> >>>>>>The root cause is identified.
> >>>>>>When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
> >>>>>>for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
> >>>>>>virtio-net kernel driver) use indirect only for Tx.
> >>>>>>I'll implement indirect support for the Rx path in vhost lib, but the
> >>>>>>change will be too big for -rc release.
> >>>>>>I propose in the mean time to disable INDIRECT_DESC feature in vhost
> >>>>>>lib, we can still enable it locally for testing.
> >>>>>>
> >>>>>>Yuanhan, is it ok for you?
> >>>>>
> >>>>>That's okay.
> >>>>I'll send a patch to disable it then.
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>Has anyone already tested Windows guest with vhost-net, which also
> >>>>has
> >>>>>>>indirect descs support?
> >>>>>>
> >>>>>>I tested and confirm it works with vhost-net.
> >>>>>
> >>>>>I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
> >>>>>for Rx path, right?
> >>>>
> >>>>No, it does support it actually.
> >>>>I thought it didn't support too, I misread the Kernel implementation of
> >>>>vhost-net and virtio-net. Acutally, virtio-net makes use of indirect
> >>>>in Rx path when mergeable buffers is disabled.
> >>>>
> >>>>The confusion certainly comes from me, sorry about that.
> >>>>
> >>>>Maxime
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Maxime Coquelin @ 2016-10-27 10:53 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: mst@redhat.com, dev@dpdk.org, vkaplans@redhat.com
In-Reply-To: <20161027103317.GM16751@yliu-dev.sh.intel.com>
On 10/27/2016 12:33 PM, Yuanhan Liu wrote:
> On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin wrote:
>> Hi Zhihong,
>>
>> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
>>> Hi Maxime,
>>>
>>> Seems indirect desc feature is causing serious performance
>>> degradation on Haswell platform, about 20% drop for both
>>> mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
>>> both iofwd and macfwd.
>> I tested PVP (with macswap on guest) and Txonly/Rxonly on an Ivy Bridge
>> platform, and didn't faced such a drop.
>
> I was actually wondering that may be the cause. I tested it with
> my IvyBridge server as well, I saw no drop.
Sorry, mine is a SandyBridge, not IvyBridge.
>
> Maybe you should find a similar platform (Haswell) and have a try?
>
> --yliu
>
>> Have you tried to pass indirect_desc=off to qemu cmdline to see if you
>> recover the performance?
>>
>> Yuanhan, which platform did you use when you tested it with zero copy?
>>
>>>
>>> I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz.
>>>
>>> Could you please verify if this is true in your test?
>> I'll try -rc1/-rc2 on my platform, and let you know.
>>
>> Thanks,
>> Maxime
>>
>>>
>>>
>>> Thanks
>>> Zhihong
>>>
>>>> -----Original Message-----
>>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>>>> Sent: Monday, October 17, 2016 10:15 PM
>>>> To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
>>>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; Xie, Huawei
>>>> <huawei.xie@intel.com>; dev@dpdk.org; vkaplans@redhat.com;
>>>> mst@redhat.com; stephen@networkplumber.org
>>>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support
>>>> to the TX path
>>>>
>>>>
>>>>
>>>> On 10/17/2016 03:21 PM, Yuanhan Liu wrote:
>>>>> On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote:
>>>>>>> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue.
>>>>>>> I'll continue the investigation early next week.
>>>>>>
>>>>>> The root cause is identified.
>>>>>> When INDIRECT_DESC feature is negotiated, Windows guest uses indirect
>>>>>> for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD &
>>>>>> virtio-net kernel driver) use indirect only for Tx.
>>>>>> I'll implement indirect support for the Rx path in vhost lib, but the
>>>>>> change will be too big for -rc release.
>>>>>> I propose in the mean time to disable INDIRECT_DESC feature in vhost
>>>>>> lib, we can still enable it locally for testing.
>>>>>>
>>>>>> Yuanhan, is it ok for you?
>>>>>
>>>>> That's okay.
>>>> I'll send a patch to disable it then.
>>>>
>>>>>
>>>>>>
>>>>>>> Has anyone already tested Windows guest with vhost-net, which also
>>>> has
>>>>>>> indirect descs support?
>>>>>>
>>>>>> I tested and confirm it works with vhost-net.
>>>>>
>>>>> I'm a bit confused then. IIRC, vhost-net also doesn't support indirect
>>>>> for Rx path, right?
>>>>
>>>> No, it does support it actually.
>>>> I thought it didn't support too, I misread the Kernel implementation of
>>>> vhost-net and virtio-net. Acutally, virtio-net makes use of indirect
>>>> in Rx path when mergeable buffers is disabled.
>>>>
>>>> The confusion certainly comes from me, sorry about that.
>>>>
>>>> Maxime
^ permalink raw reply
* Re: [PATCH v3] eal: fix libabi macro for device generalization patches
From: Shreyansh Jain @ 2016-10-27 11:10 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, ferruh.yigit
In-Reply-To: <6056365.vs23AthqBz@xps13>
Hello Thomas,
On Thursday 27 October 2016 03:45 PM, Thomas Monjalon wrote:
> 2016-10-27 12:38, Shreyansh Jain:
>> rte_device/driver generalization patches [1] were merged without a change
>> in the LIBABIVER macro. This patches bumps the macro of affected libs.
>
> It is not a macro but a Makefile variable.
Yes, I will change that.
>
>> (librte_eal was already bumped; libcryptodev and libetherdev have been
>> bumped).
>
> Please provide the commit id where EAL was bumped.
Ok. Will do.
>
>> Details of ABI/API changes:
>> - EAL (version not bumped)
>
> not bumped -> already bumped
Ok.
>
>> |- type field was removed from rte_driver
>> |- rte_pci_device now embeds rte_device
>> |- rte_pci_resource renamed to rte_mem_resource
>> |- numa_node and devargs of rte_pci_driver is moved to rte_driver
>> |- APIs for device hotplug (attach/detach) moved into EAL
>> |- API rte_eal_pci_device_name added for PCI device naming
>> |- vdev registration API introduced (rte_eal_vdrv_register,
>> | rte_eal_vdrv_unregister
>>
>> - librte_crypto (v 1=>2)
>> |- removed rte_cryptodev_create_unique_device_name API
>> |- moved device naming to EAL
>>
>> - librte_ethdev (v 4=>5)
>> |- rte_eth_dev_type is removed
>> |- removed dev_type from rte_eth_dev_allocate API
>> |- removed API rte_eth_dev_get_device_type
>> |- removed API rte_eth_dev_get_addr_by_port
>> |- removed API rte_eth_dev_get_port_by_addr
>> |- removed rte_cryptodev_create_unique_device_name API
>> |- moved device naming to EAL
>>
>> Also, deprecation notice from 16.07 has been removed and release notes for
>> 16.11 added.
>>
>> [1] http://dpdk.org/ml/archives/dev/2016-September/047087.html
>>
>> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
> [...]
>> --- a/doc/guides/rel_notes/release_16_11.rst
>> +++ b/doc/guides/rel_notes/release_16_11.rst
>> @@ -149,6 +149,32 @@ Resolved Issues
>
> It is the "Resolved Issues" section.
> Please move in the "API Changes" section.
Ok.
>
>> EAL
>> ~~~
>>
>> +* **Improved device/driver heirarchy and generalized hotplugging**
>
> typo: hierarchy
Yes.
>
>> + Device and driver relationship has been restructured by introducing generic
>> + classes. This paves way for having PCI, VDEV and other device types as
>> + just instantiated objects rather than classes in themselves. Hotplugging too
>> + has been generalized into EAL so that ethernet or crypto devices can use the
>> + common infrastructure.
>> +
>> + * removed ``pmd_type`` as way of segragation of devices
>> + * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
>> + ``rte_pci_driver``. These can now be used by any instantiated object of
>> + ``rte_driver``.
>> + * added ``rte_device`` class and all PCI and VDEV devices inherit from it
>> + * renamed devinit/devuninit handlers to probe/remove to make it more
>> + semantically correct with respect to device<=>driver relationship
>> + * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
>> + APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
>> + * helpers and support macros have been renamed to make them more synonymous
>> + with their device types
>> + (e.g. ``PMD_REGISTER_DRIVER`` => ``DRIVER_REGISTER_PCI``)
>
> It is RTE_PMD_REGISTER_PCI
It seems my Friday is earlier than usual :(
I was the one who changed it and I completely forgot about it.
>
>> + * Device naming functions have been generalized from ethdev and cryptodev
>> + to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
>> + unique device name from PCI Domain-BDF description.
>> + * Virtual device registration APIs have been added: ``rte_eal_vdrv_register``
>> + and ``rte_eal_vdrv_unregister``.
>
> Thanks
>
I am sending v4 soon.
-
Shreyansh
^ permalink raw reply
* [PATCH v4] eal: fix lib version for device generalization patches
From: Shreyansh Jain @ 2016-10-27 11:29 UTC (permalink / raw)
To: thomas.monjalon; +Cc: dev, Shreyansh Jain, ferruh.yigit
In-Reply-To: <1477552109-18624-1-git-send-email-shreyansh.jain@nxp.com>
rte_device/driver generalization patches [1] were merged without a change
in the LIBABIVER variable. This patches bumps the macro of affected libs:
- libcryptodev and libetherdev have been bumped
- librte_eal version changed in
d7e61ad3ae36 ("log: remove deprecated history dump")
Details of ABI/API changes:
- EAL [version already bumped in: d7e61ad3ae36]
|- type field was removed from rte_driver
|- rte_pci_device now embeds rte_device
|- rte_pci_resource renamed to rte_mem_resource
|- numa_node and devargs of rte_pci_driver is moved to rte_driver
|- APIs for device hotplug (attach/detach) moved into EAL
|- API rte_eal_pci_device_name added for PCI device naming
|- vdev registration API introduced (rte_eal_vdrv_register,
| rte_eal_vdrv_unregister
- librte_crypto (v 1=>2)
|- removed rte_cryptodev_create_unique_device_name API
|- moved device naming to EAL
- librte_ethdev (v 4=>5)
|- rte_eth_dev_type is removed
|- removed dev_type from rte_eth_dev_allocate API
|- removed API rte_eth_dev_get_device_type
|- removed API rte_eth_dev_get_addr_by_port
|- removed API rte_eth_dev_get_port_by_addr
|- removed rte_cryptodev_create_unique_device_name API
|- moved device naming to EAL
Also, deprecation notice from 16.07 has been removed and release notes for
16.11 added.
[1] http://dpdk.org/ml/archives/dev/2016-September/047087.html
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
--
v4:
- fix spelling mistakes and incorrect symbol name in doc
- reword commit log for EAL modification commit id
v3:
- add API/ABI change info in commit log
- fix library version change notification in release note
- fix erroneous change to librte_eal version in v2
---
doc/guides/rel_notes/deprecation.rst | 12 ------------
doc/guides/rel_notes/release_16_11.rst | 30 ++++++++++++++++++++++++++++--
lib/librte_cryptodev/Makefile | 2 +-
lib/librte_ether/Makefile | 2 +-
4 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index d5c1490..884a231 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -18,18 +18,6 @@ Deprecation Notices
``nb_seg_max`` and ``nb_mtu_seg_max`` providing information about number of
segments limit to be transmitted by device for TSO/non-TSO packets.
-* The ethdev hotplug API is going to be moved to EAL with a notification
- mechanism added to crypto and ethdev libraries so that hotplug is now
- available to both of them. This API will be stripped of the device arguments
- so that it only cares about hotplugging.
-
-* Structures embodying pci and vdev devices are going to be reworked to
- integrate new common rte_device / rte_driver objects (see
- http://dpdk.org/ml/archives/dev/2016-January/031390.html).
- ethdev and crypto libraries will then only handle those objects so that they
- do not need to care about the kind of devices that are being used, making it
- easier to add new buses later.
-
* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some fields
may be reordered to facilitate the writing of ``data_off``, ``refcnt``, and
``nb_segs`` in one operation, because some platforms have an overhead if the
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index aa0c09a..db20567 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -201,6 +201,32 @@ API Changes
* The ``file_name`` data type of ``struct rte_port_source_params`` and
``struct rte_port_sink_params`` is changed from `char *`` to ``const char *``.
+* **Improved device/driver hierarchy and generalized hotplugging**
+
+ Device and driver relationship has been restructured by introducing generic
+ classes. This paves way for having PCI, VDEV and other device types as
+ just instantiated objects rather than classes in themselves. Hotplugging too
+ has been generalized into EAL so that ethernet or crypto devices can use the
+ common infrastructure.
+
+ * removed ``pmd_type`` as way of segregation of devices
+ * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
+ ``rte_pci_driver``. These can now be used by any instantiated object of
+ ``rte_driver``.
+ * added ``rte_device`` class and all PCI and VDEV devices inherit from it
+ * renamed devinit/devuninit handlers to probe/remove to make it more
+ semantically correct with respect to device<=>driver relationship
+ * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
+ APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
+ * helpers and support macros have been renamed to make them more synonymous
+ with their device types
+ (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``)
+ * Device naming functions have been generalized from ethdev and cryptodev
+ to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
+ unique device name from PCI Domain-BDF description.
+ * Virtual device registration APIs have been added: ``rte_eal_vdrv_register``
+ and ``rte_eal_vdrv_unregister``.
+
ABI Changes
-----------
@@ -232,11 +258,11 @@ The libraries prepended with a plus sign were incremented in this version.
.. code-block:: diff
- libethdev.so.4
+ + libethdev.so.5
librte_acl.so.2
librte_cfgfile.so.2
librte_cmdline.so.2
- librte_cryptodev.so.1
+ + librte_cryptodev.so.2
librte_distributor.so.1
+ librte_eal.so.3
librte_hash.so.2
diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cryptodev/Makefile
index 314a046..aebf5d9 100644
--- a/lib/librte_cryptodev/Makefile
+++ b/lib/librte_cryptodev/Makefile
@@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_cryptodev.a
# library version
-LIBABIVER := 1
+LIBABIVER := 2
# build flags
CFLAGS += -O3
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index 488b7c8..bc2e5f6 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
EXPORT_MAP := rte_ether_version.map
-LIBABIVER := 4
+LIBABIVER := 5
SRCS-y += rte_ethdev.c
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4] eal: fix lib version for device generalization patches
From: Shreyansh Jain @ 2016-10-27 11:32 UTC (permalink / raw)
To: thomas.monjalon; +Cc: dev, ferruh.yigit
In-Reply-To: <1477567752-23039-1-git-send-email-shreyansh.jain@nxp.com>
On Thursday 27 October 2016 04:59 PM, Shreyansh Jain wrote:
> index aa0c09a..db20567 100644
> --- a/doc/guides/rel_notes/release_16_11.rst
> +++ b/doc/guides/rel_notes/release_16_11.rst
> @@ -201,6 +201,32 @@ API Changes
> * The ``file_name`` data type of ``struct rte_port_source_params`` and
> ``struct rte_port_sink_params`` is changed from `char *`` to ``const char *``.
>
> +* **Improved device/driver hierarchy and generalized hotplugging**
> +
> + Device and driver relationship has been restructured by introducing generic
> + classes. This paves way for having PCI, VDEV and other device types as
> + just instantiated objects rather than classes in themselves. Hotplugging too
> + has been generalized into EAL so that ethernet or crypto devices can use the
> + common infrastructure.
> +
> + * removed ``pmd_type`` as way of segregation of devices
> + * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
> + ``rte_pci_driver``. These can now be used by any instantiated object of
> + ``rte_driver``.
> + * added ``rte_device`` class and all PCI and VDEV devices inherit from it
> + * renamed devinit/devuninit handlers to probe/remove to make it more
> + semantically correct with respect to device<=>driver relationship
> + * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
> + APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
> + * helpers and support macros have been renamed to make them more synonymous
> + with their device types
> + (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``)
> + * Device naming functions have been generalized from ethdev and cryptodev
> + to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
> + unique device name from PCI Domain-BDF description.
> + * Virtual device registration APIs have been added: ``rte_eal_vdrv_register``
> + and ``rte_eal_vdrv_unregister``.
> +
>
> ABI Changes
> -----------
Even though I have sent the v4, there is another possibility of
splitting this log across API and ABI changes.
Problem is that most of the changes are quite related in terms of impact
on ABI and API. (some like rte_device is clear enough, though).
Any suggestions? Would repetitions be OK in release notes?
-
Shreyansh
^ permalink raw reply
* Re: [PATCH v4] eal: fix lib version for device generalization patches
From: Thomas Monjalon @ 2016-10-27 12:16 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: dev, ferruh.yigit
In-Reply-To: <9eb3805d-8f6c-c1ec-4be6-35452a3d8458@nxp.com>
2016-10-27 17:02, Shreyansh Jain:
> Even though I have sent the v4, there is another possibility of
> splitting this log across API and ABI changes.
> Problem is that most of the changes are quite related in terms of impact
> on ABI and API. (some like rte_device is clear enough, though).
> Any suggestions? Would repetitions be OK in release notes?
In general, API change implies ABI change.
I think we must use the "ABI changes" section for cases where API is not changed.
No need of repeating in both sections.
^ permalink raw reply
* Tcpdump
From: Dror Birkman @ 2016-10-27 12:25 UTC (permalink / raw)
To: dev
Hi,
I have a DPDK application that binds to an interface and processes packets.
For debugging purposes I want to run tcpdump on this interface.
IYO, what is my best option with hurting the performance of the application
too much?
TIA,
Dror
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox