Re: [dpdk-dev] [PATCH] doc: postpone legacy log functions removal
On Thu, 3 Aug 2017 16:09:02 +
"Mcnamara, John" wrote:
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Thursday, August 3, 2017 3:30 PM
> > To: dev@dpdk.org
> > Cc: olivier.m...@6wind.com
> > Subject: [dpdk-dev] [PATCH] doc: postpone legacy log functions removal
> >
> > The replacement function rte_log_get_level() has just been implemented in
> > 17.08. Better to postpone the removal of legacy functions to 17.11.
> >
> > Fixes: 4f0981e6ec6c ("eal: deprecate log functions")
> > Cc: olivier.m...@6wind.com
> >
> > Signed-off-by: Thomas Monjalon
>
> Acked-by: John McNamara
>
>
Acked-by: Olivier Matz
Thanks Thomas
Re: [dpdk-dev] [PATCH 3/3] doc: update FAQ with new testpmd default burst size
> > Signed-off-by: Bruce Richardson
>
> Acked-by: John McNamara
Fixes: 836853d3d4cf ("app/testpmd: increase default burst size to 32")
Re: [dpdk-dev] [PATCH 0/3] small documentation updates
> Bruce Richardson (3): > doc: clarify documentation on running as non-root > doc: remove unneeded TLB from title of FAQ question 2 > doc: update FAQ with new testpmd default burst size Applied, thanks
Re: [dpdk-dev] [PATCH] eal/common: minor fix for spelling and format
07/07/2017 02:36, Keith Wiles: > Signed-off-by: Keith Wiles Applied, thanks
Re: [dpdk-dev] [PATCH 5/7] doc: list NPAR as supported feature in qede
> > From: Shahed Shaikh > > > > Existing qede PMD code already supports NPAR feature. > > So adding this in "Supported Features" section after testing it with latest > > DPDK. > > > > Also, add myself to the list of maintainers of qede PMD > > Acked-by: Rasesh Mody Applied, thanks
Re: [dpdk-dev] [PATCH v3] doc: add prog_guide for the GRO library
04/08/2017 11:59, Jiayu Hu: > Add prog_guide doc to explain the design of the GRO library. > > Signed-off-by: Jiayu Hu > Acked-by: John McNamara Applied, thanks
Re: [dpdk-dev] [PATCH v2] doc: include fail-safe PMD in release note
04/08/2017 17:33, Gaetan Rivet: > Signed-off-by: Gaetan Rivet > --- > --- a/doc/guides/nics/fail_safe.rst > +++ b/doc/guides/nics/fail_safe.rst > +.. _fail_safe: > + No need of such anchor at the beginning of a doc. > Fail-safe poll mode driver library > == > --- a/doc/guides/rel_notes/release_17_08.rst > +++ b/doc/guides/rel_notes/release_17_08.rst > +* **Added Fail-Safe PMD** > + > + Added the new Fail-Safe PMD. This virtual device allows applications to > + support seamless hotplug of devices. See the :ref:`Fail-Safe > documentation` > + for more details about this driver. Replaced the :ref: by a :doc: link. With this change, applied, thanks
Re: [dpdk-dev] [PATCH] eal: add notice to make DPDK IOVA aware
On Fri, Aug 04, 2017 at 10:55:25AM +0530, Hemant Agrawal wrote: > On 8/4/2017 9:11 AM, santosh wrote: > > On Tuesday 11 July 2017 03:31 PM, Jerin Jacob wrote: > > > > > When we run DPDK on guest or VFIO mode on host, > > > the dpdk library or device will not be directly accessing > > > the physical address. Instead, the device does go through > > > an IO address translation memory management unit. On x86, > > > we call it as IOMMU and on ARM as SMMU. > > > > > > More details: > > > http://osidays.com/osidays/wp-content/uploads/2014/12/Final_OSI2014_IOMMU_DetailedView_Sanil_Anurup.pdf > > > > > > Based on discussion in the following thread > > > http://dpdk.org/ml/archives/dev/2017-July/070850.html > > > > > > We would like to change reference to physical address to more > > > appropriate name as with IOMMU/SMMU with > > > the device won't be dealing directly with the physical address. > > > > > > An ABI change is planned for 17.11 to change following > > > data structure or functions to more appropriate name. > > > Currently planned to change it iova as instead of phys > > > > > > Please note: The change will be only for the name and > > > functional aspects of the API will remain same. > > > > > > Following functions/data structures name may change. > > > This list is based on v17.05-rc1. It may change based on v17.11 code base. > > > > > > > > > typedef: > > > phys_addr_t > > > > > > structures: > > > > > > struct rte_memseg::phys_addr > > > struct rte_mbuf::buf_physaddr > > > > > > functions: > > > rte_mempool_populate_phys() > > > rte_mempool_populate_phys_tab() > > > rte_eal_using_phys_addrs() > > > rte_mem_virt2phy() > > > rte_dump_physmem_layout() > > > rte_eal_get_physmem_layout() > > > rte_eal_get_physmem_size() > > > rte_malloc_virt2phy() > > > rte_mem_phy2mch() > > > > > > > > > Signed-off-by: Jerin Jacob > > > --- > > > > Acked-by: Santosh Shukla > > > > > Acked-by: Hemant Agrawal > Acked-by: Olivier Matz
Re: [dpdk-dev] [PATCH v2] doc: announce API and ABI change for ethdev
Hi, Thomas: Need I sent another V3 patch to update commit log according to Remy's suggestion? Thanks Zhiyong > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yang, Zhiyong > Sent: Saturday, August 5, 2017 6:35 PM > To: Horton, Remy ; dev@dpdk.org > Cc: Tan, Jianfeng ; y...@fridaylinux.org; > jerin.ja...@caviumnetworks.com; tho...@monjalon.net > Subject: Re: [dpdk-dev] [PATCH v2] doc: announce API and ABI change for > ethdev > > Hi, Remy: > > > -Original Message- > > From: Horton, Remy > > Sent: Friday, August 4, 2017 2:56 PM > > To: Yang, Zhiyong ; dev@dpdk.org > > Cc: Tan, Jianfeng ; y...@fridaylinux.org; > > jerin.ja...@caviumnetworks.com; tho...@monjalon.net > > Subject: Re: [dpdk-dev] [PATCH v2] doc: announce API and ABI change > > for ethdev > > > > > > On 04/08/2017 06:27, Zhiyong Yang wrote: > > > This is an API/ABI change notice for DPDK 17.11 on redefinition of > > > port_id. port_id is defined as uint8_t by now, which is just ranged > > > from 0 to 255. For more and more scenerioes, more than 256 ports are > > > needed to support for vdev scalability. > > > > > > It is necessary for redefinition of port_id to extend from 1 bytes > > > to > > > 2 bytes. All ethdev APIs and use cases related to port_id will be > > > changed at the same time. > > > > I think this reads a little better: > > > > This is an API/ABI change notice for DPDK 17.11 announcing the > > redefinition of port_id. port_id is currently defined as uint8_t, > > which is limited to the range 0 to 255. A larger range is required for vdev > scalability. > > > > It is necessary for a redefinition of port_id to extend it from 1 bytes to > > 2 bytes. > > All ethdev APIs and usages related to port_id will be changed at the same > > time. > > Thanks Remy, of course. Your statement is better. I have a lot of things to > learn > when speaking in English. I hope I can describe things like you, a native > speaker. :) Thanks again for your ack. > > Zhiyong > > > > > > doc/guides/rel_notes/deprecation.rst | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > Acked-by: Remy Horton
Re: [dpdk-dev] DPDK qos support for 40G port
Hi Cristian, Sorry to bother again, could you give suggestions/hints of code change to support single 40G port? Because in our setup, we will use single 40G port (Intel XL710) as the network interface. Or is there any workaround to bypass the limitation?(we are not willing to use 4*10G setup) Thanks. -Original Message- From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com] Sent: Friday, August 04, 2017 5:57 PM To: Kevin Yan ; dev@dpdk.org Subject: RE: DPDK qos support for 40G port Hi Kevin, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Kevin Yan > Sent: Friday, August 4, 2017 2:55 AM > To: dev@dpdk.org > Subject: [dpdk-dev] DPDK qos support for 40G port > > Hi, > I have a question about dpdk qos feature, in > rte_sched.h, ... > rate is type of uint32_t, but if physical port rate is > 40G bit/s, which is 5G byte/s, 5G already exceed the max value of > uint32_t, so I doult that 40G is not supported by dpdk qos lib, or any error > of my understanding? > Yes, your understanding is correct, currently the port rate in bytes per second needs to be represented as 32-bit number. So, we can currently do single port with 10GbE and 25GbE rate, but not single port of 40GbE or 100GbE. Please note that we can do 40GbE as 4 ports of 10GbE each, which is a very common configuration for 40GbE. This limitation is not trivial to remove, i.e. more code is needed to remove this limitation than just changing the rate data type to uint64_t. Thanks for your feedback. Good to know that we should upgrade this library to support 40GbE rates sooner rather than later. > Thanks and waiting for your reply! > > > BRs, > Kevin > Regards, Cristian Please Note: My email address is changing. Starting May 1st 2017 my email will solely be my Mavenir email firstname.lastn...@mavenir.com. All other prior email accounts will become inactive. To ensure continuity, please send all emails to my Mavenir email ID which is currently active and available for use. This e-mail message may contain confidential or proprietary information of Mavenir Systems, Inc. or its affiliates and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies in your control and contact us by e-mailing to secur...@mavenir.com. Thank You. This message contains the views of its author and may not necessarily reflect the views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor email messages, but make no representation that such messages are authorized, secure, uncompromised, or free from computer viruses, malware, or other defects.
