* [PATCH] lib/librte_mempool: a redundant of socket_id assignment
From: Wei Zhao @ 2016-11-14 2:15 UTC (permalink / raw)
To: dev; +Cc: olivier.matz, zhao wei
From: zhao wei <wei.zhao1@intel.com>
There is a redundant repetition mempool socket_id assignment in the
file rte_mempool.c in function rte_mempool_create_empty.The
statement "mp->socket_id = socket_id;"appear twice in line 821
and 824.One of them is redundant, so delete it.
Fixes: 85226f9c526b ("lib/librte_mempool: mempool:introduce
a function to create an empty pool")
Signed-off-by: zhao wei <wei.zhao1@intel.com>
---
lib/librte_mempool/rte_mempool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aa513b9..1c2aed8 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -818,7 +818,6 @@ rte_mempool_create_empty(const char *name, unsigned n, unsigned elt_size,
goto exit_unlock;
}
mp->mz = mz;
- mp->socket_id = socket_id;
mp->size = n;
mp->flags = flags;
mp->socket_id = socket_id;
--
2.5.5
^ permalink raw reply related
* [dpdk-announce] DPDK 16.11 released
From: Thomas Monjalon @ 2016-11-13 22:22 UTC (permalink / raw)
To: announce
A new major release is available:
http://fast.dpdk.org/rel/dpdk-16.11.tar.xz
It has been built by an important community:
728 patches from 119 authors
773 files changed, 60728 insertions(+), 1220384 deletions(-)
There are 56 new contributors
(including authors, reviewers and testers):
Thanks to Alain Leon, Aleksey Katargin, Alex Zelezniak, Ali Volkan Atli,
Amine Kherbouche, Ananda Sathyanarayana, Ben Walker, Byron Marohn,
Daniele Di Proietto, Daniel Verkamp, Deirdre O'Connor, Elad Persiko,
E. Scott Daniels, Frederico Cadete, Gary Mussar, Gowrishankar Muthukrishnan,
Guolin Yang, Guruprasad Rao, James Poole, Jason Wang, Jean Tourrilhes,
Jiayu Hu, John Carney, John Ousterhout, Jon Loeliger, Jozef Martiniak,
Juho Snellman, Karmarkar Suyash, Luca Boccassi, Masoud Hasanifard,
Matthias Gatto, Mohammad Abdul Awal, Morten Brørup, Nikhil Jagtap,
Ning Li, Nipun Gupta, Olivier Gournet, Patrick Kutch, Pierre Pfister,
Qiming Yang, Qi Zhang, Rahul R Shah, Sagi Grimberg, Saikrishna Edupuganti,
Sarath Somasekharan, Souvik Dey, Tal Avraham, Tao Y Yang, Vincent Guo,
Wang Wei, Weiliang Luo, Wei Zhao, Xuekun Hu, Yangchao Zhou, Yunjian Wang,
Zhiyong Yang.
These new contributors are associated with these domain names:
163.com, 6wind.com, annapurnalabs.com, argela.com.tr, att.com,
broadcom.com, brocade.com, ciena.com, cisco.com, corp.free.fr,
cs.stanford.edu, gmail.com, grimberg.me, huawei.com, iki.fi,
intel.com, jd.com, labs.hpe.com, linux.vnet.ibm.com, mellanox.com,
netgate.com, nxp.com, oneaccess-net.com, outscale.com, redhat.com,
research.att.com, smartsharesystems.com, sonusnet.com,
versa-networks.com, vmware.com,
Some highlights:
- new device object model
- more networking offloads
- improved vhost
- virtio for NEON on ARM
- new crypto libraries (ZUC and OpenSSL)
More details in the release notes:
http://dpdk.org/doc/guides/rel_notes/release_16_11.html
The new features for the 17.02 cycle must be submitted before December 4.
There is a long list of expected works:
http://dpdk.org/dev/roadmap
It means we will have a huge workload to properly review all the new stuff
before the end of the year. Do not forget to help reviewing patches from
others if we want to have a chance to integrate everything in time.
Other works in progress:
- A structure in Linux Foundation is being discussed at moving@dpdk.org
http://dpdk.org/ml/listinfo/ci
- A CI process is being discussed at ci@dpdk.org
http://dpdk.org/ml/listinfo/moving
Thanks everyone
^ permalink raw reply
* Re: pmdinfogen issues: cross compilation for ARM fails with older host compiler
From: Jerin Jacob @ 2016-11-13 20:59 UTC (permalink / raw)
To: Hemant Agrawal
Cc: Neil Horman, dev@dpdk.org, users@dpdk.org, Jacob, Jerin,
Jan Viktorin
In-Reply-To: <DB5PR04MB1605F64CF0D986E0B2B26AF089BB0@DB5PR04MB1605.eurprd04.prod.outlook.com>
On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> Hi Neil,
> Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
> However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
> e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.
>
> /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
> register uint16_t x = _x;
> asm volatile ("rev16 %0,%1"
> : "=r" (x)
> : "r" (x)
> );
> return x;
> }
> #endif
>
> One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
> e.g
> #if !(defined __arm__ || defined __aarch64__)
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
> return (_x >> 8) | ((_x << 8) & 0xff00);
> }
> #else ….
>
> Is there a better way to fix it?
IMO, It is a HOST build infrastructure issue. If a host app is using the
dpdk service then it should compile and link against HOST target(in this
specific case, build/x86_64-native-linuxapp-gcc). I think, introducing the
HOSTTARGET kind of scheme is a clean solution.
/Jerin
^ permalink raw reply
* Re: [PATCH] improve git diff
From: Thomas Monjalon @ 2016-11-13 14:21 UTC (permalink / raw)
To: dev
In-Reply-To: <1478706261-31261-1-git-send-email-thomas.monjalon@6wind.com>
2016-11-09 16:44, Thomas Monjalon:
> Sometimes git does not print the name of the function being changed
> after @@. It happens especially after a goto label which is not indented.
> Giving a hint about the languages of files .c, .h and .py
> will improve hunk headers of "git diff" rendering.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Applied
^ permalink raw reply
* Re: [PATCH v1] doc: rearrange the high level documentation index
From: Thomas Monjalon @ 2016-11-13 14:20 UTC (permalink / raw)
To: John McNamara; +Cc: dev
In-Reply-To: <1478871955-6106-1-git-send-email-john.mcnamara@intel.com>
2016-11-11 13:45, John McNamara:
> Rearrange the order of the high level documenation index into
> a more logical sequence for a new user.
>
> Also, improve some of the high-level document names.
>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v1] doc: fix release notes for 16.11
From: Thomas Monjalon @ 2016-11-13 14:16 UTC (permalink / raw)
To: John McNamara; +Cc: dev
In-Reply-To: <1478865882-15315-1-git-send-email-john.mcnamara@intel.com>
2016-11-11 12:04, John McNamara:
> Fix grammar, spelling and formatting of DPDK 16.11 release notes.
>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] doc: announce ABI change for ethtool app enhance
From: Thomas Monjalon @ 2016-11-13 13:57 UTC (permalink / raw)
To: Yang, Qiming; +Cc: dev, Zhang, Helin
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E717F59FDF@SHSMSX103.ccr.corp.intel.com>
> > This patch adds a notice that the ABI change for ethtool app to get the NIC
> > firmware version in the 17.02 release.
> >
> > Signed-off-by: Qiming Yang <qiming.yang@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
Acked-by: Beilei Xing <beilei.xing@intel.com>
> Acked-by: Helin Zhang <helin.zhang@intel.com>
^ permalink raw reply
* Re: [PATCH v1] doc: announce API and ABI change for librte_ether
From: Thomas Monjalon @ 2016-11-13 13:46 UTC (permalink / raw)
To: Iremonger, Bernard; +Cc: dev, Ferruh Yigit, Mcnamara, John
In-Reply-To: <f423d7ea-0db8-7a54-b0a3-8d0aec492d39@intel.com>
> >> In 17.02 five rte_eth_dev_set_vf_*** functions will be removed from
> >> librte_ether, renamed and moved to the ixgbe PMD.
> >>
> >> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> >
> > Acked-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Reshma Pattan <reshma.pattan@intel.com>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Applied
^ permalink raw reply
* Re: [PATCH v1] doc: announce API change for ethdev function
From: Thomas Monjalon @ 2016-11-13 9:16 UTC (permalink / raw)
To: Iremonger, Bernard; +Cc: dev, Mcnamara, John
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264A8ED@IRSMSX103.ger.corp.intel.com>
> > The _rte_eth_dev_call_process function will change to return "int"
> > and a fourth parameter "void* ret_param" will be added. This change
> > targets release 17.02.
> >
> > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
The real API change is in rte_eth_dev_cb_fn but we understand the idea.
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Applied
^ permalink raw reply
* Re: [PATCH] doc: announce API and ABI changes for librte_eal
From: Thomas Monjalon @ 2016-11-13 9:02 UTC (permalink / raw)
To: Shreyansh Jain
Cc: Pattan, Reshma, Neil Horman, dev, Yigit, Ferruh, David Marchand
In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F010C38CE@IRSMSX109.ger.corp.intel.com>
> > >> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
> > >
> > > Acked-by: David Marchand <david.marchand@6wind.com>
> >
> > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> Acked-by: Reshma Pattan <reshma.pattan@intel.com>
Applied
^ permalink raw reply
* Re: [PATCH] doc: remove iomem and ioport handling in igb_uio
From: Thomas Monjalon @ 2016-11-13 8:55 UTC (permalink / raw)
To: Jianfeng Tan; +Cc: Remy Horton, dev, ferruh.yigit, david.marchand
In-Reply-To: <330ff7fe-77e3-5ec9-7d2b-081ecb741877@intel.com>
> > Suggested-by: Yigit, Ferruh <ferruh.yigit@intel.com>
> > Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
>
> Acked-by: Remy Horton <remy.horton@intel.com>
Applied
^ permalink raw reply
* Re: [PATCH] doc: add more tested platforms and nics and OSes
From: Thomas Monjalon @ 2016-11-12 21:46 UTC (permalink / raw)
To: Pei, Yulong; +Cc: Mcnamara, John, dev
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264CD52@IRSMSX103.ger.corp.intel.com>
> > Add more tested platforms and nics and OSes to the release notes.
> >
> > Signed-off-by: Yulong Pei <yulong.pei@intel.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v2] doc: add known issue on QAT PMD into release notes
From: Thomas Monjalon @ 2016-11-12 21:37 UTC (permalink / raw)
To: John Griffin; +Cc: dev, Fiona Trahe, pablo.de.lara.guarch
In-Reply-To: <5824B8CF.8010104@intel.com>
> > Issue is with the digest appended feature on QAT PMD.
> > A workaround is also documented.
> >
> > Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> > Acked-by: John McNamara <john.mcnamara@intel.com>
> Acked-by: John Griffin <john.griffin@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] pdump: fix log message to display correct error number
From: Thomas Monjalon @ 2016-11-12 21:29 UTC (permalink / raw)
To: Pattan, Reshma; +Cc: dev, De Lara Guarch, Pablo, Reshma Pattan
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8973CA259E8@IRSMSX108.ger.corp.intel.com>
> > The ethdev Rx/Tx remove callback apis doesn't set rte_errno during
> > failures, instead they just return negative error number, so using
> > that number in logs instead of rte_errno upon Rx and Tx callback
> > removal failures.
> >
> > Fixes: 278f9454 ("pdump: add new library for packet capture")
> >
> > Signed-off-by: Reshma Pattan <reshma.pattan@gmail.com>
>
> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] app/test: fix crash of lpm test
From: Thomas Monjalon @ 2016-11-12 21:21 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, Dai, Wei, Richardson, Bruce
In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D63A2ED275@PGSMSX106.gar.corp.intel.com>
> > The test recently added accesses to lpm->tbl8[ip >> 8] with is much larger than
> > the size of the table, causing a crash of the test application.
> >
> > Fix this typo by replacing tbl8 by tbl24.
> >
> > Fixes: 231fa88ed522 ("app/test: verify LPM tbl8 recycle")
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> Acked-by: Wei Dai <wei.dai@intle.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v2] mempool: Free memzone if mempool populate phys fails
From: Thomas Monjalon @ 2016-11-12 21:07 UTC (permalink / raw)
To: Nipun Gupta; +Cc: dev, Olivier Matz, Hemant Agrawal
In-Reply-To: <b8df8799-6d53-1a33-f5eb-94ea9bf23f9c@6wind.com>
> > This patch fixes the issue of memzone not being freed incase the
> > rte_mempool_populate_phys fails in the rte_mempool_populate_default
> >
> > This issue was identified when testing with OVS ~2.6
> > - configure the system with low memory (e.g. < 500 MB)
> > - add bridge and dpdk interfaces
> > - delete brigde
> > - keep on repeating the above sequence.
> >
> > Fixes: d1d914ebbc25 ("mempool: allocate in several memory chunks by default")
> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
>
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v2] net/qede: fix unknown speed errmsg for 25G link
From: Thomas Monjalon @ 2016-11-12 21:03 UTC (permalink / raw)
To: Harish Patil; +Cc: dev, Dept-EngDPDKDev
In-Reply-To: <1478886096-22105-1-git-send-email-harish.patil@qlogic.com>
2016-11-11 09:41, Harish Patil:
> - Fix to use bitmapped values in NVM configuration for speed capability
> advertisement. This issue is specific to 25G NIC since it is capable
> of 25G and 10G speeds.
>
> - Update feature list.
>
> Fixes: 64c239b7f8b7 ("net/qede: fix advertising link speed capability")
>
> Signed-off-by: Harish Patil <harish.patil@qlogic.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] improve git diff
From: Thomas Monjalon @ 2016-11-12 20:51 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <59b9b8bf-1b90-8055-74f7-eecd6fe9c41a@intel.com>
2016-11-11 17:28, Ferruh Yigit:
> On 11/11/2016 4:21 PM, Thomas Monjalon wrote:
> > 2016-11-11 11:22, Ferruh Yigit:
> >> On 11/9/2016 3:44 PM, Thomas Monjalon wrote:
> >>> Sometimes git does not print the name of the function being changed
> >>> after @@. It happens especially after a goto label which is not indented.
> >>> Giving a hint about the languages of files .c, .h and .py
> >>> will improve hunk headers of "git diff" rendering.
> >>>
> >>> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> > [...]
> >>> --- /dev/null
> >>> +++ b/.gitattributes
> >>> @@ -0,0 +1,3 @@
> >>> +*.c diff=cpp
> >>> +*.h diff=cpp
> >>
> >> Can't git auto detect to use C/C++ language diff use for .c/.h files?
> >
> > No
> >
> >> Do you have a sample that generates bad hunk header, just to test?
> >
> > Yes, you'll find a lot of them with "git log -p | grep '@@.*:'"
> > Example:
> > git show bb6722f | grep '@@.*:'
> > Without the patch, it is a goto label in the hunk header.
> >
>
> You are right, I was expecting better from git J
Sometimes, less is more :)
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Shreyansh Jain @ 2016-11-12 17:44 UTC (permalink / raw)
To: Ferruh Yigit, David Marchand; +Cc: dev@dpdk.org
In-Reply-To: <1a19615c-1121-fed4-b34f-aa0f4b654085@intel.com>
Hello Ferruh,
(Please ignore if line wrappings are not correct. Using a possibly
unconfigured mail client).
> -----Original Message-----
> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
> Sent: Saturday, November 12, 2016 12:46 AM
> To: Shreyansh Jain <shreyansh.jain@nxp.com>; David Marchand
> <david.marchand@6wind.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Clarification for eth_driver changes
>
> On 11/10/2016 11:05 AM, Shreyansh Jain wrote:
> > Hello David,
> >
> > On Thursday 10 November 2016 01:46 PM, David Marchand wrote:
> >> Hello Shreyansh,
> >>
> >> On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain <shreyansh.jain@nxp.com>
> wrote:
> >>> I need some help and clarification regarding some changes I am doing to
> >>> cleanup the EAL code.
> >>>
> >>> There are some changes which should be done for eth_driver/rte_eth_device
> >>> structures:
> >>>
> >>> 1. most obvious, eth_driver should be renamed to rte_eth_driver.
> >>> 2. eth_driver currently has rte_pci_driver embedded in it
> >>> - there can be ethernet devices which are _not_ PCI
> >>> - in which case, this structure should be removed.
> >>
> >> Do we really need to keep a eth_driver ?
> >
> > No. As you have rightly mentioned below (as well as in your Jan'16
> > post), it is a mere convenience.
>
> Isn't it good to separate the logic related which bus device connected
> and what functionality it provides. Because these two can be flexible:
Indeed. The very idea of a Bus model is to make a hierarchy which allows
for pluggability/flexibility in terms of devices being used. But, until now I
have only considered placement hierarchy and not functional hierarchy. (more
below)
>
> device -> virtual_bus -> ethernet_functionality
> device -> pci_bus -> crypto_functionality
> device -> x_bus -> y_function
>
Ok.
>
> what about:
>
> create generic bus driver/device and all eal level deal with generic
> bus. different buses inherit from generic bus logic
From what I had in mind: (and very much similar to what you have already
mentioned in this email)
- a generic bus (not a driver, not a device). I don't know how to categorize
a bus. It is certainly not a device, and then handler for a bus (physical)
can be considered a 'bus driver'. So, just 'rte_bus'.
- there is a bus for each physical implementation (or virtual). So, a rte_bus
Object for PCI, VDEV, ABC, DEF and so on.
- Buses are registered just like a PMD - RTE_PMD_BUS_REGISTER()
-- There is a problem of making sure the constructor for bus registration is
executed before drivers. Probably by putting the bus code within lib*
- Each registered bus is part of a doubly list.
- Each device inherits rte_bus
- Each driver inherits rte_bus
- Existing Device and Drivers lists would be moved into rte_bus
(more below)
>
> create generic functionality device/driver and pmd level deal with
> these. different functionalities inherit from generic functionality logic
>
> and use rte_device/rte_driver as glue logic for all these.
>
> This makes easy to add new bus or functionality device/drivers without
> breaking existing logic.
>
>
> Something like this:
>
> struct rte_device {
> char *name;
> struct rte_driver *drv;
> struct rte_bus_device *bus_dev;
> struct rte_funcional_device *func_dev;
> *devargs
> }
>
> struct rte_bus_device {
> struct rte_device *dev;
> /* generic bus device */
> }
This is where you lost me. From what I understood from your text:
(CMIIW)
- Most abstract class is 'rte_device'.
- A bus is a device. So, it points to a rte_device
- But, a rte_device belongs to a bus, so it points to a rte_bus_device.
Isn't that contradictory?
This is how I view the physical layout of devices on which DPDK works:
+---------+ +----------+
|Driver 1A| |Driver 2B |
|servicing| |servicing | (*)
|Bus A | |Bus B |
+---------+ +----------+
\ /
+---------+ +-------+
| bus A |---| bus B |--- ...
+---------+ +-------+
/ \ \ \
/ \_ \ \
+---------+ / / \
| device 1| / +--------+ \
| on Bus A| / |Device 3| |
+---------+ / |on bus B| |
+---------+ +--------+ |
| device 2| +--------+
| on Bus A| |Device 4|
+---------+ |on bus B|
+--------+
(*) Multiple drivers servicing a Bus.
Now, if we introduce the abstraction for functionality (assuming net/crypto) as
two functionalities currently applicable:
+---------+ +----------+
|Driver 1A| |Driver 2B |
|servicing| |servicing | (*)
|Bus A | |Bus B |
+---------' +---.------+
\ /
+---------+ +-------+
| bus A |---| bus B |--- ...
+---------+ +-------+
/ \ \ \
/ \_ \ \
+---------' / / \
| device 1| / +--------' \
| on Bus A| / |Device 3| |
+---------+ / |on bus B| |
/ +---------' +-|------+ |
| | device 2| / +-------'+
| | on Bus A| / |Device 4|
\ +--|------+ _____/ |on bus B|
\ \_____ / +--------+
| .--\' /
| / \ ___/
+-'----'-+ +'------'+
|Func X | |Func Y |
|(Net) | |(Crypto)|
+--------| +--------+
So that means, a device would be a 'net' or 'crypto' device bases on the
Functionality it attaches to.
From a physical layout view, is that correct understanding of your argument?
>
> struct rte_pci_device {
> struct rte_bus_device bus_dev;
> /* generic pci bus */
> }
>
> struct rte_vdev_device {
> struct rte_bus_device bus_dev;
> /* generic vdev bus */
> }
>
> struct rte_funcional_device {
> struct rte_device *dev;
> }
I understand your point of 'pluggable' functionality. It would be helpful if
same driver would like to move between being a crypto and net. But is that a
plausible use case for DPDK right now?
To me, it seems as one more layer of redirection/abstraction.
This is what the view I have as of now:
__ rte_bus_list
/
+----------'---+
|rte_bus |
| driver_list |
| device_list |
| scan |
| match |
| remove |
| ..some refcnt|
+--|------|----+
_________/ \_________
+--------/----+ +-\--------------+
|rte_device | |rte_driver |
| rte_bus | | rte_bus |
| flags (3*) | | probe (1*) |
| init | | remove |
| uninit | | ... |
+---||--------+ | drv_flags |
|| | intr_handle(2*)|
| \ +----------\\\---+
| \_____________ \\\
| \ |||
+------|---------+ +----|----------+ |||
|rte_pci_device | |rte_xxx_device | (4*) |||
| PCI specific | | xxx device | |||
| info (mem,) | | specific fns | / | \
+----------------+ +---------------+ / | \
_____________________/ / \
/ ___/ \
+-------------'--+ +------------'---+ +--'------------+
|rte_pci_driver | |rte_vdev_driver | |rte_xxx_driver |
| PCI id table, | | <probably, | | .... |
| other driver | | nothing> | +---------------+
| data | +----------------+
+----------------+
(1*) Problem is that probe functions have different arguments. So,
generalizing them might be some rework in the respective device
layers
(2*) Interrupt handling for each driver type might be different. I am not
sure how to generalize that either. This is grey area for me.
(3*) Probably exposing a bitmask for device capabilities. Nothing similar
exists now to relate it. Don't know if that is useful. Allowing
applications to question a device about what it supports and what it
doesn't - making it more flexible at application layer (but more code
as well.)
(4*) Even vdev would be an instantiated as a device. It is not being done
currently.
So, unlike your model, rte_bus remains the topmost class which is neither a
device, not a driver. It is just a class.
Further, as specific information exists in each specific device and driver,
that is not generalized.
>
> struct rte_eth_device {
> struct rte_funcional_device func_dev;
> /* generic eth device */
> }
>
> struct rte_crypto_device {
> struct rte_funcional_device func_dev;
> /* generic crypto device */
> }
>
I tried thinking of this breakup but I couldn't understand what common things
a rte_functional_device would contain except init/uninit (similar to what you
have also mentioned below) which can be part of rte_device itself.
>
> struct rte_driver {
> char *name;
> struct rte_device *dev;
> struct rte_bus_driver *bus_drv;
> struct rte_funcional_driver *func_drv;
> }
>
> struct rte_bus_driver {
> struct rte_driver *drv;
> rte_bus_probe_t *probe(dev, drv);
> rte_bus_remove_t *remove(dev);
> /* generic bus driver */
> }
I still think a bus is neither a device, nor a driver. Yes, if we draw
physical analogy, buses are indeed devices on PCB - but they are not anything
functional with respect to an application view. They exist only to provide way
for application to understand device layout.
>
> struct rte_pci_driver {
> struct rte_bus_driver bus_drv;
> *id_table;
> /* generic pci bus */
> }
>
> struct rte_vdev_driver {
> struct rte_bus_driver bus_drv;
> /* generic vdev bus */
> }
>
> struct rte_funcional_driver {
> struct rte_driver *drv;
> rte_funcional_init_t *init;
> rte_funcional_uninit_t *uninit;
> }
>
> struct rte_eth_driver {
> struct rte_funcional_driver func_drv;
> /* generic eth driver */
> }
>
> struct rte_crypto_driver {
> struct rte_funcional_driver func_drv;
> /* generic crypto driver */
> }
>
> pci_scan_one()
> {
> dev = create();
> pci_dev = create();
>
> dev->bus_dev = pci_dev;
> pci_dev->bus_dev.dev = dev;
>
> insert(bus_dev_list);
> }
>
> register_drv(drv)
> {
> insert(bus_drv_list)
> insert(func_drv_list)
> insert(drv_list)
> }
>
> rte_eal_bus_probe()
> for bus_dev in bus_dev_list
> bus_probe_all_drivers(bus_dev)
> for bus_drv in bus_drv_list
> bus_probe_one_driver(bus_drv, bus_dev)
> bus_dev->dev->drv = bus_drv->drv;
> bus_drv->drv->dev = bus_dev->dev;
> probe(drv, dev)
>
Agree.
> probe(drv, dev)
> {
> dev->func_dev = create();
In my case, it would be creating a rte_device; rte_pci_dev in case of
PCI probe, pointing back to rte_device, rte_bus of PCI type.
> func_dev->dev = dev;
>
> func_drv = drv->func_drv;
> func_drv->init(func_dev);
Effectively, it would be rte_device->init();
> }
>
> eht_init(func_dev)
> {
> eth_dev = (struct rte_eth_dev)func_dev;
> drv = func_dev->dev->drv;
> }
>
>
I am not against what you have stated. Creating a functional device is just
one more layer of abstraction in my view. Mostly abstraction/classification
makes life easier for applications to visualize underlying hierarchy. If this
serves a purpose, I am OK with that. At least right now, I think it would
only end up being like eth_driver which is just a holder.
__
Shreyansh
^ permalink raw reply
* reassembly app doesn't send pkt
From: Victor Detoni @ 2016-11-12 13:29 UTC (permalink / raw)
To: dev, users
Hi,
When I test ip_reassembly app on vmxnet3 nic works fine, but when I change
to the nics 82599ES 10-Gigabit SFI/SFP+, it stop to send the packet
"reassembled" on tx nic.
when I remove the code bellow on rte_ipv4_reassembly.c source code, it
sends pkt but truncated.
rte_pktmbuf_chain(fp->frags[IP_FIRST_FRAG_IDX].mb, m);
Anybody has some tip? I printed all functions like send_single_packet and
send_burst and it seems Ok, when I compare ping pkt and udp frag pkt.
^ permalink raw reply
* Re: pmdinfogen issues: cross compilation for ARM fails with older host compiler
From: Neil Horman @ 2016-11-11 19:25 UTC (permalink / raw)
To: Jan Viktorin; +Cc: Hemant Agrawal, dev@dpdk.org, users@dpdk.org, Jacob, Jerin
In-Reply-To: <20161111144851.3154a651@pcviktorin.fit.vutbr.cz>
On Fri, Nov 11, 2016 at 02:48:51PM +0100, Jan Viktorin wrote:
> Hello all,
>
> On Fri, 11 Nov 2016 10:34:39 +0000
> Hemant Agrawal <hemant.agrawal@nxp.com> wrote:
>
> > Hi Neil,
> > Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
>
> This seems wierd to me... why is it so? I couldn't find any usage of rte_byteorder.h in the source of pmdinfogen
> (what am I missing?). Why is it included there?
>
See the CONVERT_NATIVE macro in pmdinfogen.h. It makes use of the various
rte_[le|be]_to_cpu macros from rte_byteorder.h
> The pmdinfogen executes on the host but works with the (cross-compiled) target binaries. Is that right? If the tool
> needs to know endianity then we probably need a header telling just the target's endianity (or other metadata).
>
pmdinfogen works on ELF object files, and can extract the endianess from the ELF
header itself (using the e_ident[EI_DATA] area).
> > However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
> > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.
>
> This is not the actual issue. Consider an ARM build server that cross-compiles DPDK for Intel x86 (I admit that this
> is quite a ridiculous situation, so take it easy ;)). Then we have just opposite issues... Would we like to fill the
> DPDK x86 code base with #ifdef...#endif everytime there is some assembly code? I'd just like to point out that this
> single instruction is not the true source of the problem. It is like complaining that nasm cannot compile Thumb2
> instructions... No it cannot, sorry.
>
It sounds like the issue is a general 'how to get support for another arch'
question. In the case of rte_byteorder.h, its actually pretty cut and dry,
because thankfully all the instructions are wrapped up into nice C inline
functions or macros. The trick is to simply define the api instructions in the
file for each arch, with a default generic case that just uses C, so it can be
compiled into whatever the target arch needs (although it may run more slowly).
That gets you initial support, and then you can optimize be creating a special
case for the new arch. You have to do that for every API set that has per-arch
optimizations (the atomic ops, the tsc ops, memcpy, cpuflags, prefetch, etc).
Its time consuming, but its just the way it is.
> >
> > /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> > #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> > register uint16_t x = _x;
> > asm volatile ("rev16 %0,%1"
> > : "=r" (x)
> > : "r" (x)
> > );
> > return x;
> > }
> > #endif
> >
> > One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
> > e.g
> > #if !(defined __arm__ || defined __aarch64__)
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> > return (_x >> 8) | ((_x << 8) & 0xff00);
> > }
> > #else ….
> >
> > Is there a better way to fix it?
>
Well, almost, what you have above is a good solution, but it shouldn't be the
ARM solution, it should be the code used if an arch specific variant of the code
isn't defined. The pattern rte_byteorder should follow is
#if (defined i686 || defined x86_64)
<x86 specific implementation of rte_arch_bswap16>
#elif (defined ppc || ppc64)
<ppc specific implementation of rte_arch_bswap16>
#else
<generic implementation of rte_arch_bswap16>
#endif
The idea is to have a generic version that works for any arch to fall back on,
then if you have a faster way to do it on your arch, you can add a clause at
your leisure to do so.
Neil
> In my opinion, this would work as a hotfix but not as a solution.
>
> Kind regards
> Jan
>
> >
> > Regards,
> > Hemant
> >
> >
> > From: Michael Wildt [mailto:michael.wildt@broadcom.com]
> > Sent: Wednesday, September 14, 2016 7:18 PM
> > To: Hemant Agrawal <hemant.agrawal@nxp.com>
> > Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; users@dpdk.org
> > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and pmdinfogen issues
> >
> > Hi Hemant,
> >
> > Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 but good to know.
> >
> > I gave that one a try and that works as well but as with the 5.3 I have to be on a Ubuntu not RHEL6 to make it work.
> >
> > Thanks,
> > Michael
> >
> > On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal <hemant.agrawal@nxp.com<mailto:hemant.agrawal@nxp.com>> wrote:
> > Hi Michael,
> > One of the problem, I found with Linaro gcc 4.9 toolchain for i686 (default one), that it seems to be built with older kernel headers (<3.8). This usages older linux/vhost.h file.
> >
> > However, we have not observed this issue with x86_64 based toolchain on 64 bit m/c.
> > https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
> >
> > Regards,
> > Hemant
> >
> > > -----Original Message-----
> > > From: users [mailto:users-bounces@dpdk.org<mailto:users-bounces@dpdk.org>] On Behalf Of Michael Wildt
> > > Sent: Wednesday, September 14, 2016 12:05 AM
> > > To: Thomas Monjalon <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> > > Cc: users@dpdk.org<mailto:users@dpdk.org>
> > > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and
> > > pmdinfogen issues
> > >
> > > Hi Thomas,
> > >
> > > The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a test
> > > application. Its actually 4.9.2.
> > >
> > > Tried a newer Linaro tool chain, turned out to be a bit more complicated since
> > > that does not work on RHEL6, is however a success. With Linaro 5.3 one can
> > > cross compile dpdk fine with no errors, though the rte_byteorder.h file still
> > > points to arm's version, but pmdinfogen builds.
> > >
> > > Probably should still fix both issues just to keep the base clean.
> > >
> > > At least I have a workaround in the interim.
> > >
> > > Thanks for the help.
> > >
> > > Thanks,
> > > Michael
> > >
> > >
> > > On Tue, Sep 13, 2016 at 11:07 AM, Thomas Monjalon
> > > <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>
> > > > wrote:
> > >
> > > > 2016-09-13 07:45, Michael Wildt:
> > > > > Hi Thomas,
> > > > >
> > > > > Appreciate the assistance. Please see inline.
> > > > >
> > > > >
> > > > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <
> > > > thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > 2016-09-12 22:20, Michael Wildt:
> > > > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 target.
> > > > This
> > > > > > > fails in the following areas, using latest dpdk as of 9/12. When
> > > > > > compiling
> > > > > > > natively there are no issues.
> > > > > >
> > > > > > Your analysis below seems good.
> > > > > > Interestingly, I do not see such error (don't know why).
> > > > > > Please could you share the commands you are using?
> > > > > >
> > > > >
> > > > > Sure can.
> > > > >
> > > > > make config T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > > > bin/aarch64-linux-gnu-
> > > > > ARCH=arm64
> > > > >
> > > > > make T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > > > bin/aarch64-linux-gnu-
> > > > > ARCH=arm64 RTE_KERNELDIR=/projects/kernel
> > > > >
> > > > > > > - librte_vhost, fails with:
> > > > > > >
> > > > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-
> > > > > > net-user.c:250:23:
> > > > > > > error: array subscript is above array bounds [-Werror=array-bounds]
> > > > > > > rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];
> > > > > > [...]
> > > > > > > - buildtools/pmdinfogen, fails with:
> > > > > > >
> > > > > > > == Build buildtools/pmdinfogen
> > > > > > > HOSTCC pmdinfogen.o
> > > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_byteorder.h:
> > > > > > > Assembler messages:
> > > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_
> > > > byteorder.h:53:
> > > > > > > Error: no such instruction: `rev16 %bx,%bx'
> > > > > > [...]
> > > > > > > - The issue is due to the rte_byteorder.h file which gets
> > > > > > > symlink'ed with the ARM version at the beginning of the build.
> > > > > > > The pmdinfogen is always compiled for x86 thus the asm is failing.
> > > >
> > > > It is definitely something to fix.
> > > > In the meantime, you should be able to compile DPDK by using a more
> > > > recent toolchain. This error is in:
> > > >
> > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > > >
> > > > I know you are using gcc-4.9 but maybe __GNUC_MINOR__ is wrong in yours.
> > > >
> > > >
> >
>
>
>
> --
> Jan Viktorin E-mail: Viktorin@RehiveTech.com
> System Architect Web: www.RehiveTech.com
> RehiveTech
> Brno, Czech Republic
>
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Ferruh Yigit @ 2016-11-11 19:16 UTC (permalink / raw)
To: Shreyansh Jain, David Marchand; +Cc: dev@dpdk.org
In-Reply-To: <86ece536-1574-6d84-661e-9b9e77180344@nxp.com>
On 11/10/2016 11:05 AM, Shreyansh Jain wrote:
> Hello David,
>
> On Thursday 10 November 2016 01:46 PM, David Marchand wrote:
>> Hello Shreyansh,
>>
>> On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>>> I need some help and clarification regarding some changes I am doing to
>>> cleanup the EAL code.
>>>
>>> There are some changes which should be done for eth_driver/rte_eth_device
>>> structures:
>>>
>>> 1. most obvious, eth_driver should be renamed to rte_eth_driver.
>>> 2. eth_driver currently has rte_pci_driver embedded in it
>>> - there can be ethernet devices which are _not_ PCI
>>> - in which case, this structure should be removed.
>>
>> Do we really need to keep a eth_driver ?
>
> No. As you have rightly mentioned below (as well as in your Jan'16
> post), it is a mere convenience.
Isn't it good to separate the logic related which bus device connected
and what functionality it provides. Because these two can be flexible:
device -> virtual_bus -> ethernet_functionality
device -> pci_bus -> crypto_functionality
device -> x_bus -> y_function
what about:
create generic bus driver/device and all eal level deal with generic
bus. different buses inherit from generic bus logic
create generic functionality device/driver and pmd level deal with
these. different functionalities inherit from generic functionality logic
and use rte_device/rte_driver as glue logic for all these.
This makes easy to add new bus or functionality device/drivers without
breaking existing logic.
Something like this:
struct rte_device {
char *name;
struct rte_driver *drv;
struct rte_bus_device *bus_dev;
struct rte_funcional_device *func_dev;
*devargs
}
struct rte_bus_device {
struct rte_device *dev;
/* generic bus device */
}
struct rte_pci_device {
struct rte_bus_device bus_dev;
/* generic pci bus */
}
struct rte_vdev_device {
struct rte_bus_device bus_dev;
/* generic vdev bus */
}
struct rte_funcional_device {
struct rte_device *dev;
}
struct rte_eth_device {
struct rte_funcional_device func_dev;
/* generic eth device */
}
struct rte_crypto_device {
struct rte_funcional_device func_dev;
/* generic crypto device */
}
struct rte_driver {
char *name;
struct rte_device *dev;
struct rte_bus_driver *bus_drv;
struct rte_funcional_driver *func_drv;
}
struct rte_bus_driver {
struct rte_driver *drv;
rte_bus_probe_t *probe(dev, drv);
rte_bus_remove_t *remove(dev);
/* generic bus driver */
}
struct rte_pci_driver {
struct rte_bus_driver bus_drv;
*id_table;
/* generic pci bus */
}
struct rte_vdev_driver {
struct rte_bus_driver bus_drv;
/* generic vdev bus */
}
struct rte_funcional_driver {
struct rte_driver *drv;
rte_funcional_init_t *init;
rte_funcional_uninit_t *uninit;
}
struct rte_eth_driver {
struct rte_funcional_driver func_drv;
/* generic eth driver */
}
struct rte_crypto_driver {
struct rte_funcional_driver func_drv;
/* generic crypto driver */
}
pci_scan_one()
{
dev = create();
pci_dev = create();
dev->bus_dev = pci_dev;
pci_dev->bus_dev.dev = dev;
insert(bus_dev_list);
}
register_drv(drv)
{
insert(bus_drv_list)
insert(func_drv_list)
insert(drv_list)
}
rte_eal_bus_probe()
for bus_dev in bus_dev_list
bus_probe_all_drivers(bus_dev)
for bus_drv in bus_drv_list
bus_probe_one_driver(bus_drv, bus_dev)
bus_dev->dev->drv = bus_drv->drv;
bus_drv->drv->dev = bus_dev->dev;
probe(drv, dev)
probe(drv, dev)
{
dev->func_dev = create();
func_dev->dev = dev;
func_drv = drv->func_drv;
func_drv->init(func_dev);
}
eht_init(func_dev)
{
eth_dev = (struct rte_eth_dev)func_dev;
drv = func_dev->dev->drv;
}
^ permalink raw reply
* [PATCH v2] net/qede: fix unknown speed errmsg for 25G link
From: Harish Patil @ 2016-11-11 17:41 UTC (permalink / raw)
To: dev; +Cc: Dept-EngDPDKDev, Harish Patil
In-Reply-To: <1478744784-17469-1-git-send-email-Rasesh.Mody@cavium.com>
- Fix to use bitmapped values in NVM configuration for speed capability
advertisement. This issue is specific to 25G NIC since it is capable
of 25G and 10G speeds.
- Update feature list.
Fixes: 64c239b7f8b7 ("net/qede: fix advertising link speed capability")
Signed-off-by: Harish Patil <harish.patil@qlogic.com>
---
config/common_base | 2 +-
doc/guides/nics/features/qede.ini | 1 +
doc/guides/nics/features/qede_vf.ini | 1 +
doc/guides/nics/qede.rst | 2 +-
drivers/net/qede/qede_ethdev.c | 15 ++++++++++++++-
drivers/net/qede/qede_if.h | 2 +-
drivers/net/qede/qede_main.c | 25 ++-----------------------
7 files changed, 21 insertions(+), 27 deletions(-)
diff --git a/config/common_base b/config/common_base
index 21d18f8..4bff83a 100644
--- a/config/common_base
+++ b/config/common_base
@@ -315,7 +315,7 @@ CONFIG_RTE_LIBRTE_PMD_BOND=y
CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB=n
CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
-# QLogic 25G/40G/100G PMD
+# QLogic 10G/25G/40G/100G PMD
#
CONFIG_RTE_LIBRTE_QEDE_PMD=y
CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
diff --git a/doc/guides/nics/features/qede.ini b/doc/guides/nics/features/qede.ini
index 1f3c3f6..7d75030 100644
--- a/doc/guides/nics/features/qede.ini
+++ b/doc/guides/nics/features/qede.ini
@@ -4,6 +4,7 @@
; Refer to default.ini for the full list of available PMD features.
;
[Features]
+Speed capabilities = Y
Link status = Y
Link status event = Y
MTU update = Y
diff --git a/doc/guides/nics/features/qede_vf.ini b/doc/guides/nics/features/qede_vf.ini
index 1c0f228..acb1b99 100644
--- a/doc/guides/nics/features/qede_vf.ini
+++ b/doc/guides/nics/features/qede_vf.ini
@@ -4,6 +4,7 @@
; Refer to default.ini for the full list of available PMD features.
;
[Features]
+Speed capabilities = Y
Link status = Y
Link status event = Y
MTU update = Y
diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
index b6f54fd..d22ecdd 100644
--- a/doc/guides/nics/qede.rst
+++ b/doc/guides/nics/qede.rst
@@ -71,7 +71,7 @@ Non-supported Features
Supported QLogic Adapters
-------------------------
-- QLogic FastLinQ QL4xxxx 25G/40G/100G CNAs.
+- QLogic FastLinQ QL4xxxx 10G/25G/40G/100G CNAs.
Prerequisites
-------------
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 59129f2..d106dd0 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -647,6 +647,7 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
struct qede_dev *qdev = eth_dev->data->dev_private;
struct ecore_dev *edev = &qdev->edev;
struct qed_link_output link;
+ uint32_t speed_cap = 0;
PMD_INIT_FUNC_TRACE(edev);
@@ -681,7 +682,19 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
memset(&link, 0, sizeof(struct qed_link_output));
qdev->ops->common->get_link(edev, &link);
- dev_info->speed_capa = rte_eth_speed_bitflag(link.adv_speed, 0);
+ if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G)
+ speed_cap |= ETH_LINK_SPEED_1G;
+ if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G)
+ speed_cap |= ETH_LINK_SPEED_10G;
+ if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G)
+ speed_cap |= ETH_LINK_SPEED_25G;
+ if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_40G)
+ speed_cap |= ETH_LINK_SPEED_40G;
+ if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G)
+ speed_cap |= ETH_LINK_SPEED_50G;
+ if (link.adv_speed & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_BB_100G)
+ speed_cap |= ETH_LINK_SPEED_100G;
+ dev_info->speed_capa = speed_cap;
}
/* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/qede/qede_if.h b/drivers/net/qede/qede_if.h
index 4936349..2131fe2 100644
--- a/drivers/net/qede/qede_if.h
+++ b/drivers/net/qede/qede_if.h
@@ -70,7 +70,7 @@ struct qed_link_output {
uint32_t advertised_caps; /* In ADVERTISED defs */
uint32_t lp_caps; /* In ADVERTISED defs */
uint32_t speed; /* In Mb/s */
- uint32_t adv_speed; /* In Mb/s */
+ uint32_t adv_speed; /* Speed mask */
uint8_t duplex; /* In DUPLEX defs */
uint8_t port; /* In PORT defs */
bool autoneg;
diff --git a/drivers/net/qede/qede_main.c b/drivers/net/qede/qede_main.c
index d2e476c..ab22409 100644
--- a/drivers/net/qede/qede_main.c
+++ b/drivers/net/qede/qede_main.c
@@ -488,7 +488,6 @@ static void qed_fill_link(struct ecore_hwfn *hwfn,
struct ecore_mcp_link_state link;
struct ecore_mcp_link_capabilities link_caps;
uint32_t media_type;
- uint32_t adv_speed;
uint8_t change = 0;
memset(if_link, 0, sizeof(*if_link));
@@ -516,28 +515,8 @@ static void qed_fill_link(struct ecore_hwfn *hwfn,
if_link->duplex = QEDE_DUPLEX_FULL;
- /* Fill up the native advertised speed */
- switch (params.speed.advertised_speeds) {
- case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G:
- adv_speed = 10000;
- break;
- case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G:
- adv_speed = 25000;
- break;
- case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_40G:
- adv_speed = 40000;
- break;
- case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G:
- adv_speed = 50000;
- break;
- case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_BB_100G:
- adv_speed = 100000;
- break;
- default:
- DP_NOTICE(hwfn, false, "Unknown speed\n");
- adv_speed = 0;
- }
- if_link->adv_speed = adv_speed;
+ /* Fill up the native advertised speed cap mask */
+ if_link->adv_speed = params.speed.advertised_speeds;
if (params.speed.autoneg)
if_link->supported_caps |= QEDE_SUPPORTED_AUTONEG;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] improve git diff
From: Ferruh Yigit @ 2016-11-11 17:28 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
In-Reply-To: <1616077.gDs2nMcLPh@xps13>
On 11/11/2016 4:21 PM, Thomas Monjalon wrote:
> 2016-11-11 11:22, Ferruh Yigit:
>> On 11/9/2016 3:44 PM, Thomas Monjalon wrote:
>>> Sometimes git does not print the name of the function being changed
>>> after @@. It happens especially after a goto label which is not indented.
>>> Giving a hint about the languages of files .c, .h and .py
>>> will improve hunk headers of "git diff" rendering.
>>>
>>> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> [...]
>>> --- /dev/null
>>> +++ b/.gitattributes
>>> @@ -0,0 +1,3 @@
>>> +*.c diff=cpp
>>> +*.h diff=cpp
>>
>> Can't git auto detect to use C/C++ language diff use for .c/.h files?
>
> No
>
>> Do you have a sample that generates bad hunk header, just to test?
>
> Yes, you'll find a lot of them with "git log -p | grep '@@.*:'"
> Example:
> git show bb6722f | grep '@@.*:'
> Without the patch, it is a goto label in the hunk header.
>
You are right, I was expecting better from git J
^ permalink raw reply
* Re: [PATCH v1] doc: rearrange the high level documentation index
From: Thomas Monjalon @ 2016-11-11 16:48 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264D84C@IRSMSX103.ger.corp.intel.com>
2016-11-11 13:53, Mcnamara, John:
> I would prefer not to have some of these are highest level items such as
> "Xen Guide", and possibly "Crypto Device Drivers". Perhaps we could push
> them down a level with "Network Interface Controller Drivers" under a
> "Devices and Drivers" (or similar) section like:
>
> * ...
> * Programmer's Guide
> * HowTo Guides
> * DPDK Tools User Guides
> * Devices and Drivers
> * Network Interface Controller Drivers
> * Crypto Device Drivers
> * Xen Guide
Yes it may be an idea.
But as we will continue to support Xen Dom0, I think Xen should have
a special place somewhere (in Linux guide or separated)?
^ 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