[dpdk-dev] rte_hash_del_key crash in multi-process environment
Thanks so much! That fixes my problem.
At 2016-04-19 15:39:16, "De Lara Guarch, Pablo" wrote:
>Hi,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ??
>> Sent: Tuesday, April 19, 2016 5:58 AM
>> To: De Lara Guarch, Pablo
>> Cc: Thomas Monjalon; Gonzalez Monroy, Sergio; dev at dpdk.org; Dhana
>> Eadala; Richardson, Bruce; Qiu, Michael
>> Subject: [dpdk-dev] rte_hash_del_key crash in multi-process environment
>>
>> Hi all,
>>
>>
>> In the multi-process environment, before I met a bug when calling
>> rte_hash_lookup_with_hash. Using Dhana's patch fixed my problem. Now I
>> need to remove the flow in the multi-process environment, the system gets
>> crashed when calling rte_hash_del_key function. The following is the gdb
>> trace. Does anybody meet this problem or know how to fix it?
>
>First of all, another fix for the multi-process support was implemented and
>merged for 16.04 release,
>so take a look at it, if you can.
>Regarding the rte_hash_del_key() function, you should use
>rte_hash_del_key_with_hash,
>if you want to use it in a multi-process environment (as you did for the
>lookup function).
>
>Thanks,
>Pablo
>
>>
>>
>>
>>
>> Program received signal SIGILL, Illegal instruction.
>>
>> 0x0048a0dd in rte_port_ring_reader_frag_free
>> (port=0x7ffe113d4100) at /home/zhangwei1984/timopenNetVM/dpdk-
>> 2.2.0/lib/librte_port/rte_port_frag.c:266
>>
>> 266return -1;
>>
>> (gdb) bt
>>
>> #0 0x0048a0dd in rte_port_ring_reader_frag_free
>> (port=0x7ffe113d4100) at /home/zhangwei1984/timopenNetVM/dpdk-
>> 2.2.0/lib/librte_port/rte_port_frag.c:266
>>
>> #1 0x0049c537 in rte_hash_del_key (h=0x7ffe113d4100,
>> key=0x7ffe092e1000)
>>
>>at /home/zhangwei1984/timopenNetVM/dpdk-
>> 2.2.0/lib/librte_hash/rte_cuckoo_hash.c:917
>>
>> #2 0x0043716a in onvm_ft_remove_key (table=0x7ffe113c3e80,
>> key=0x7ffe092e1000) at /home/zhangwei1984/onvm-shared-
>> cpu/onvm/shared/onvm_flow_table.c:160
>>
>> #3 0x0043767e in onvm_flow_dir_del_and_free_key
>> (key=0x7ffe092e1000) at /home/zhangwei1984/onvm-shared-
>> cpu/onvm/shared/onvm_flow_dir.c:144
>>
>> #4 0x00437619 in onvm_flow_dir_del_key (key=0x7ffe092e1000) at
>> /home/zhangwei1984/onvm-shared-
>> cpu/onvm/shared/onvm_flow_dir.c:128
>>
>> #5 0x00423ded in remove_flow_rule (idx=3) at
>> /home/zhangwei1984/onvm-shared-cpu/examples/flow_dir/flow_dir.c:130
>>
>> #6 0x00423e44 in clear_stat_remove_flow_rule
>> (nf_info=0x7fff3e652100) at /home/zhangwei1984/onvm-shared-
>> cpu/examples/flow_dir/flow_dir.c:145
>>
>> #7 0x004247e3 in alloc_nfs_install_flow_rule (services=0xd66e90
>> , pkt=0x7ffe13f56400)
>>
>>at /home/zhangwei1984/onvm-shared-
>> cpu/examples/flow_dir/flow_dir.c:186
>>
>> #8 0x00424bdb in packet_handler (pkt=0x7ffe13f56400,
>> meta=0x7ffe13f56440) at /home/zhangwei1984/onvm-shared-
>> cpu/examples/flow_dir/flow_dir.c:294
>>
>> #9 0x0043001d in onvm_nf_run (info=0x7fff3e651b00,
>> handler=0x424b21 ) at /home/zhangwei1984/onvm-
>> shared-cpu/onvm/onvm_nf/onvm_nflib.c:462
>>
>> #10 0x00424cc2 in main (argc=3, argv=0x7fffe660) at
>> /home/zhangwei1984/onvm-shared-cpu/examples/flow_dir/flow_dir.c:323
>>
>>
>>
>>
>>
>>
>>
>>
>> At 2016-03-23 03:53:43, "De Lara Guarch, Pablo"
>> wrote:
>> >Hi Thomas,
>> >
>> >> -Original Message-
>> >> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> >> Sent: Tuesday, March 22, 2016 11:42 AM
>> >> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio
>> >> Cc: dev at dpdk.org; Dhana Eadala; Richardson, Bruce; Qiu, Michael
>> >> Subject: Re: [dpdk-dev] [PATCH] hash: fix memcmp function pointer in
>> multi-
>> >> process environment
>> >>
>> >> Hi,
>> >>
>> >> Pablo, Sergio, please could you help with this issue?
>> >
>> >I agree this is not the best way to fix this. I will try to have a fix
>> >without
>> having to use ifdefs.
>> >
>> >Thanks,
>> >Pablo
>> >>
>> >> 2016-03-13 22:16, Dhana Eadala:
>> >> > We found a problem in dpdk-2.2 using under multi-process
>> environment.
>> >> > Here is the brief description how we are using the dpdk:
>> >> >
>> >> > We have two processes proc1, proc2 using dpdk. These proc1 and proc2
>> >> are
>> >> > two different compiled binaries.
>> >> > proc1 is started as primary process and proc2 as secondary process.
>> >> >
>> >> > proc1:
>> >> > Calls srcHash = rte_hash_create("src_hash_name") to create rte_hash
>> >> structure.
>> >> > As part of this, this api initalized the rte_hash structure and set the
>> >> > srcHash->rte_hash_cmp_eq to the address of memcmp() from proc1
>> >> address space.
>> >> >
>> >> > proc2:
>> >> > calls srcHash = rte_hash_find_existing("src_hash_name").
>> >> > This function call returns the rte_hash created by proc1.
>> >> > This srcHash->rte_hash_cmp_eq still points to the address of
>> >> > memcmp() from proc1 address space.
>> >> > Later proc2 c
[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build
> >2016-03-31 19:15, Rasesh Mody: >> --- a/scripts/test-build.sh >> +++ b/scripts/test-build.sh >> @@ -116,6 +116,7 @@ config () # >> test "$DPDK_DEP_ZLIB" != y || \ >> sed -ri 's,(BNX2X_PMD=)n,\1y,' $1/.config >> sed -ri's,(NFP_PMD=)n,\1y,' $1/.config >> +sed -ri 's,(QEDE_PMD=)n,\1y,' $1/.config > >As QEDE is enabled in common_base, we do not need to add it >in test-build.sh. > Sure. Thanks, Harish
[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build
> >2016-03-31 19:15, Rasesh Mody: >> --- a/config/common_base >> +++ b/config/common_base >> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24 >> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48 > >It looks to be some tuning which could be done at runtime. Isn't it? That?s right. Can you please suggest if there is any better option to make it a runtime? There is no PMD API for that. > >> +CONFIG_RTE_LIBRTE_QEDE_TX_SWITCHING=y > >Is it possible to enable this feature at runtime? For now, I can remove this config since it is only applicable for SR-IOV PF which we don?t have it currently. > >> +#Provides path/name of the firmware file >> +CONFIG_RTE_LIBRTE_QEDE_FW=n > >Should we replace n by a string? >Why not defaults to an empty string? > > Okay, I shall change it. Thanks, Harish
[dpdk-dev] [PATCH v5 05/10] qede: Add core driver
Hi Thomas, > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, April 19, 2016 5:59 AM > > 2016-03-31 19:15, Rasesh Mody: > > +ifeq ($(OS_TYPE),Linux) > > +CFLAGS_ECORE_DRIVER += -Wno-shift-negative-value endif > > I see an error with clang: > fatal error: unknown warning option '-Wno-shift-negative-value'; > did you mean '-Wno-shift-sign-overflow'? We had compiled all our v5 driver patches against clang v3.8 on RH7.1 and didn't see a similar error. "clang version 3.8.0 (trunk 249596) (llvm/trunk 249595)" The '-Wno-shift-negative-value' option only got introduced after 3.6.0 clang release. Pls. let us know if we need to support a minimum version of clang. We had asked this question earlier in the dpdk community, however we didn't hear back from anyone so far. Thanks! Rasesh
[dpdk-dev] [PATCH v5 05/10] qede: Add core driver
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, April 19, 2016 6:18 AM > > 2016-03-31 19:15, Rasesh Mody: > > The Qlogic Everest Driver for Ethernet(QEDE) Poll Mode Driver(PMD) is > > the DPDK specific module for QLogic FastLinQ QL4 25G/40G CNA > > family of adapters as well as their virtual functions (VF) in SR-IOV > > context. > > > > This patch adds QEDE PMD, which interacts with base driver and > > initialises the HW. > > After removing the BIT_MACRO check (see http://dpdk.org/patch/12113) > and other false positives, there is only one warning from checkpatches.sh: > > CHECK:CONCATENATED_STRING: Concatenated strings should use spaces > between elements > #1933: FILE: drivers/net/qede/qede_main.c:152: > + DP_NOTICE(edev, false, "Invalid fw size: %" PRIu64"\n", Will fix it.
[dpdk-dev] perfomance of rte_lpm rule subsystem
I just realizied that my patch could be confusing. I want to emphasize that it contains two completly different and independent set of changes. One is new rule subsystem and the other is 64 bit next hop. Maybe I should've prepared a patch with only rule changes, but I wanted to discuss fist and if there would be interest spend some time and make the final patch containing only rule changes. Please ignore the next hop changes. They have nothing to do with rule subsystem changes. The rule changes don't need new next hop and I don't want 64 bit next hop to be part of dpdk. >> Hi. >> >> Doing some test with rte_lpm (adding/deleting bgp full table rules) I >> noticed that >> rule subsystem is very slow even considering that probably it was never >> designed for using >> in a data forwarding plane. So I want to propose some changes to the "rule" >> subsystem. >> >> I reimplemented rule part ot the lib using rte_hash, and perfomance of >> adding/deleted routes have increased dramatically. >> If increasing speed of adding deleting routes makes sence for anybody else >> I would like to discuss my patch. >> The patch also include changes that make next_hop 64 bit, so please just >> ignore them. The rule changes are in the following >> functions only: >> >> rte_lpm2_create >> >> rule_find >> rule_add >> rule_delete >> find_previous_rule >> delete_depth_small >> delete_depth_big >> >> rte_lpm2_add >> rte_lpm2_delete >> rte_lpm2_is_rule_present >> rte_lpm2_delete_all
[dpdk-dev] basic forwarding example not working
Hi, I think your log is cut short. At least in what you posted I don't see the "card skipped" issue anymore. Also I don't see the segfault at the end anymore. Actually there is no error left in this second log. I never used basicfwd so far - maybe it is something special to it that breaks your case. If it follows the normal EAL commandline I'd recommend to also add something for memory like --socket-mem 2048. Well without it should just try to grab everything, but I prefer to specify things. Could you try to run the testpmd or l2fwd programs instead - IMHO these are more commonly used (=usually work better). Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Tue, Apr 19, 2016 at 7:30 PM, Subbu CS wrote: > Hi Christian, > > I unbind two interfaces and then bound them to uio_pci_generic driver. > > [root at localhost tools]# ./dpdk_nic_bind.py --status > > Network devices using DPDK-compatible driver > > :00:0a.0 'Virtio network device' drv=uio_pci_generic unused=igb_uio > :00:0b.0 'Virtio network device' drv=uio_pci_generic unused=igb_uio > > Network devices using kernel driver > === > :00:03.0 'RTL-8100/8101L/8139 PCI Fast Ethernet Adapter' if=ens3 > drv=8139cp unused=igb_uio,uio_pci_generic *Active* > :00:08.0 'Virtio network device' if= drv=virtio-pci > unused=igb_uio,uio_pci_generic > :00:09.0 'Virtio network device' if= drv=virtio-pci > unused=igb_uio,uio_pci_generic > > Other network devices > = > > > > > But Still I get the same error > > > [root at localhost build]# ./basicfwd -c 1 -n 2 > EAL: Detected lcore 0 as core 0 on socket 0 > EAL: Support maximum 128 logical core(s) by configuration. > EAL: Detected 1 lcore(s) > EAL: Probing VFIO support... > EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or > directory) > EAL: VFIO modules not loaded, skipping VFIO support... > EAL: Setting up physically contiguous memory... > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f189d60 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f189d20 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f189ce0 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f189ca0 (size = 0x20) > EAL: Ask a virtual area of 0x2740 bytes > EAL: Virtual area found at 0x7f187540 (size = 0x2740) > EAL: Ask a virtual area of 0x4a0 bytes > EAL: Virtual area found at 0x7f187080 (size = 0x4a0) > EAL: Ask a virtual area of 0x120 bytes > EAL: Virtual area found at 0x7f186f40 (size = 0x120) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f186f00 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f186ec0 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f186e80 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f186e40 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f186e00 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f186dc0 (size = 0x20) > EAL: Requesting 370 pages of size 2MB from socket 0 > EAL: TSC frequency is ~1696076 KHz > EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using > unreliable clock cycles ! > EAL: Master lcore 0 is ready (tid=9e7a58c0;cpuset=[0]) > EAL: PCI device :00:08.0 on NUMA socket -1 > EAL: probe driver: 1af4:1000 rte_virtio_pmd > EAL: Not managed by a supported kernel driver, skipped > Segmentation fault > > > > On Tue, Apr 19, 2016 at 9:53 PM, Christian Ehrhardt < > christian.ehrhardt at canonical.com> wrote: > >> Hi, >> for virtio-pci devices you should either just unbind them or bind them to >> one of the generic drivers like uio_pci_generic. >> At least I never saw igb_uio on virtio-pci devices. >> >> There might be more complete answers, but I think that should get you >> going. >> >> >> Christian Ehrhardt >> Software Engineer, Ubuntu Server >> Canonical Ltd >> >> On Tue, Apr 19, 2016 at 6:00 PM, Subbu CS >> wrote: >> >>> I am using two virtio network adapter on VM on KVM host. >>> >>> As in following output, I have bound both interface with igb_uio driver >>> >>> ./dpdk_nic_bind.py --bind=igb_uio 00:0a.0 >>> ./dpdk_nic_bind.py --bind=igb_uio 00:0b.0 >>> >>> [root at localhost tools]# ./dpdk_nic_bind.py --status >>> >>> Network devices using DPDK-compatible driver >>> >>> :00:0a.0 'Virtio network device' drv=igb_uio unused= >>> :00:0b.0 'Virtio network device' drv=igb_uio unused= >>> >>> Network devices using kernel driver >>> === >>> :00:03.0 'RTL-8100/8101L/813
[dpdk-dev] TSO support for Virtio_pmd
Hi all, I see some additions in dpdk 16.04 to support TSO for vhost-user dpdk driver with vanilla linux virtio VM. Does dpdk Virtio driver support TSO with the current code? if not, is there any plan to support it in the future? Thanks, Nissim
[dpdk-dev] Memory leak when adding/removing vhost_user ports
On Wed, Apr 20, 2016 at 7:04 AM, Yuanhan Liu wrote: > On Tue, Apr 19, 2016 at 06:33:50PM +0200, Christian Ehrhardt wrote: > [...] > > With that applied one (and only one) of my two guests looses > connectivity after > > removing the ports the first time. > > Yeah, that's should be because I invoked the "->destroy_device()" > callback. > Shouldn't that not only destroy the particular vhost_user device I remove? See below for some better details on the test to clarify that. BTW, I'm curious how do you do the test? I saw you added 256 ports, but > with 2 guests only? So, 254 of them are idle, just for testing the > memory leak bug? > Maybe I should describe it better: 1. Spawn some vhost-user ports (40 in my case) 2. Spawn a pair of guests that connect via four of those ports per guest 3. Guests only intialize one of that vhost_user based NICs 4. check connectivity between guests via the vhost_user based connection (working at this stage) LOOP 5-7: 5. add ports 41-512 6. remove ports 41-512 7. check connectivity between guests via the vhost_user based connection So the vhost_user ports the guests are using are never deleted. Only some extra (not even used) ports are added&removed in the loop to search for potential leaks over a longer lifetime of an openvswitch-dpdk based solution.
[dpdk-dev] compile error on ubuntu 14.4.4 kernel 4.2.0-27-generic in qemu
Root cause: Default cpu config when the VM has be been started by qemu does not support SSE. I have resolved this issue. Here the resolution which I used. Might be helpful for others Method 1 After Configuring VM by GUI based Virtual Machine Manager, go to the CPU config & make SSE as "Required" Method 2 pass -cpu options to qemu-system-x86_64 with your cpu type [Nehalem] in my case. -cpu Nehalem,+rdtscp,+x2apic,+dca,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme Thanks to *Masaru OKI & * *Christian Ehrhardt for the info*
[dpdk-dev] TSO support for Virtio_pmd
Hi Nissim, On 4/20/2016 2:10 PM, Nissim Nisimov wrote: > Hi all, > > I see some additions in dpdk 16.04 to support TSO for vhost-user dpdk driver > with vanilla linux virtio VM. > > Does dpdk Virtio driver support TSO with the current code? Virtio pmd driver does not support TSO for now. > if not, is there any plan to support it in the future? Previously, it's implemented in the v3 of the patchset, which you are referring to, but abandoned in the v4. v3: http://thread.gmane.org/gmane.comp.networking.dpdk.devel/27512 v8: http://thread.gmane.org/gmane.comp.networking.dpdk.devel/32743 It may be because that there's no consumers (L4 stack) for this feature. And if you want that, you could make that as a reference. Thanks, Jianfeng > > Thanks, > Nissim
[dpdk-dev] [PATCH 2/3 v7] i40e: Add floating VEB support in i40e
> @@ -3830,12 +3844,22 @@ i40e_vsi_release(struct i40e_vsi *vsi)
> i40e_veb_release(vsi->veb);
> }
>
> + if (vsi->floating_veb) {
> + TAILQ_FOREACH(vsi_list, &vsi->floating_veb->head, list) {
> + if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
> + return -1;
It will be better to continue but not return error.
> + TAILQ_REMOVE(&vsi->floating_veb->head, vsi_list,
> list);
> + }
> + i40e_veb_release(vsi->floating_veb);
> + }
> +
> diff --git a/drivers/net/i40e/i40e_ethdev.h
> b/drivers/net/i40e/i40e_ethdev.h index 7dc6936..09fb6e2 100644
> --- a/drivers/net/i40e/i40e_ethdev.h
> +++ b/drivers/net/i40e/i40e_ethdev.h
> @@ -224,6 +224,7 @@ struct i40e_bw_info { struct i40e_veb {
> struct i40e_vsi_list_head head;
> struct i40e_vsi *associate_vsi; /* Associate VSI who owns the VEB */
> + struct i40e_pf *associate_pf; /* Associate PF who owns the VEB */
> uint16_t seid; /* The seid of VEB itself */
> uint16_t uplink_seid; /* The uplink seid of this VEB */
> uint16_t stats_idx;
> @@ -264,6 +265,7 @@ struct i40e_vsi {
> struct i40e_vsi_list sib_vsi_list; /* sibling vsi list */
> struct i40e_vsi *parent_vsi;
> struct i40e_veb *veb;/* Associated veb, could be null */
> + struct i40e_veb *floating_veb; /* Associated floating veb */
For vsi->veb, the VEB associated with uplink vsi, but as I know, floating_veb
Has no uplink vsis. Can I understand the floating_veb in vsi indicates floating
veb
Of the device/pf, and only main vsi will have it? If so, why not put in in the
pf structure?
[dpdk-dev] ixgbe : query regarding your code changes for VF mac add
Hi Santosh, I do not get exactly what you attempt to do on a VF. Are you first deleting the so-called permanent MAC address by a call to the function ixgbevf_remove_mac_addr() ? This operation is not allowed. Can you explain exactly the sequence of operations that are done, so that I can understand how the test (memcmp(hw->mac.perm_addr, mac_addr, sizeof(struct ether_addr)) == 0) in the function ixgbevf_add_mac_addr() prevents them to be successfully performed. Ivan PS : please, can you CC your emails to dev at dpdk.org 2016-04-19 17:01 GMT+02:00 santosh : > Hi Ivan, > > Your following code changes causing issue in Vmware environment. > > --- --- > -- > + /* > + * On a 82599 VF, adding again the same MAC addr is not an idempotent > + * operation. Trap this case to avoid exhausting the [very limited] > + * set of PF resources used to store VF MAC addresses. > + */ > + if (memcmp(hw->mac.perm_addr, mac_addr, sizeof(struct ether_addr)) == 0) > + return; > diag = ixgbevf_set_uc_addr_vf(hw, 2, mac_addr->addr_bytes); > > - --- > > > Issue: > At CLI , we have provision to add /del MAC of an interface. > During MAC delete, existing MAC is deleted and default MAC is applied. > This default MAC is not being applied in VMware environment > successfully due to "return" statement > in your above code changes. As a result traffic is stopped completely. > If I remove above > "return" statement then traffic continues to flow after MAC delete. > > Please let me know your suggestion to handle this scenario . If I > remove "return" what will be the consequences ? > > If removing "return" statement is not good idea then what are other > way to handle MAC delete scenario ? we have only 1 VF per PF in our > setup as of now. > > > Thanks > Santosh > -- Ivan BOULE 6WIND Software Engineer Tel: +33 1 39 30 92 47 Mob: + 33 6 77 25 26 38 Fax: +33 1 39 30 92 11 ivan.boule at 6wind.com www.6wind.com Join the Multicore Packet Processing Forum: www.multicorepacketprocessing.com Ce courriel ainsi que toutes les pi?ces jointes, est uniquement destin? ? son ou ses destinataires. Il contient des informations confidentielles qui sont la propri?t? de 6WIND. Toute r?v?lation, distribution ou copie des informations qu'il contient est strictement interdite. Si vous avez re?u ce message par erreur, veuillez imm?diatement le signaler ? l'?metteur et d?truire toutes les donn?es re?ues. This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to 6WIND. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build
2016-04-20 00:14, Harish Patil: > >2016-03-31 19:15, Rasesh Mody: > >> --- a/config/common_base > >> +++ b/config/common_base > >> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24 > >> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48 > > > >It looks to be some tuning which could be done at runtime. Isn't it? > > That?s right. Can you please suggest if there is any better option to make > it a runtime? There is no PMD API for that. There are some devargs for that. For PCI dev, it can be passed in the whitelist option. We should remove this limitation by having a devargs API (and command line options) independent of whitelisting.
[dpdk-dev] [PATCH v5 05/10] qede: Add core driver
2016-04-20 01:09, Rasesh Mody: > Hi Thomas, > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Tuesday, April 19, 2016 5:59 AM > > > > 2016-03-31 19:15, Rasesh Mody: > > > +ifeq ($(OS_TYPE),Linux) > > > +CFLAGS_ECORE_DRIVER += -Wno-shift-negative-value endif > > > > I see an error with clang: > > fatal error: unknown warning option '-Wno-shift-negative-value'; > > did you mean '-Wno-shift-sign-overflow'? > > We had compiled all our v5 driver patches against clang v3.8 on RH7.1 and > didn't see a similar error. > "clang version 3.8.0 (trunk 249596) (llvm/trunk 249595)" > > The '-Wno-shift-negative-value' option only got introduced after 3.6.0 clang > release. Pls. let us know if we need to support a minimum version of clang. > We had asked this question earlier in the dpdk community, however we didn't > hear back from anyone so far. I use clang-3.6.2. You are right there is no official requirement in doc/guides/linux_gsg/sys_reqs.rst. Opinions about minimal version to support?
[dpdk-dev] [PATCH] remove poisoned flags
On Tue, Apr 19, 2016 at 10:19 PM, Thomas Monjalon wrote: > Some flags were poisoned after having been removed from EAL and mbuf > in releases 1.8 (b10eef348d, 62814bc2e9) and 2.0 (4769bc5a27cc). > After several releases, they have probably disappeared from the applications. > > Signed-off-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH] eal: remove useless internal function from memcpy headers
On Tue, Apr 19, 2016 at 10:47 PM, Thomas Monjalon wrote: > The function rte_memcpy_func() is used in ARM and PPC implementations > of rte_memcpy(). > There are some useless copies in Tile and some ARM branches. > It was also declared without doxygen comment in the generic header. > > Signed-off-by: Thomas Monjalon Looks good to me. Acked-by: David Marchand -- David Marchand
[dpdk-dev] Couple of PMD questions
On Tue, Apr 19, 2016 at 03:16:37PM -0500, Jay Rolette wrote: > In ixgbe_dev_rx_init(), there is this bit of code: > > /* >* Configure the RX buffer size in the BSIZEPACKET field of >* the SRRCTL register of the queue. >* The value is in 1 KB resolution. Valid values can be from >* 1 KB to 16 KB. >*/ > buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mb_pool) - > RTE_PKTMBUF_HEADROOM); > srrctl |= ((buf_size >> IXGBE_SRRCTL_BSIZEPKT_SHIFT) & > IXGBE_SRRCTL_BSIZEPKT_MASK); > > IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(rxq->reg_idx), srrctl); > > buf_size = (uint16_t) ((srrctl & IXGBE_SRRCTL_BSIZEPKT_MASK) << > IXGBE_SRRCTL_BSIZEPKT_SHIFT); > > /* It adds dual VLAN length for supporting dual VLAN */ > if (dev->data->dev_conf.rxmode.max_rx_pkt_len + > 2 * IXGBE_VLAN_TAG_SIZE > buf_size) > dev->data->scattered_rx = 1; > > > Couple of questions I have about it: > > 1) If the caller configured the MBUF memory pool data room size to be > something other than a multiple of 1K (+ RTE_PKTMBUF_HEADROOM), then the > driver ends up silently programming the NIC to use a smaller max RX size > than the caller specified. > > Should the driver error out in that case instead of only "sort of" working? > If not, it seems like it should be logging an error message. Well, it does log at the end of the whole rx init process what RX function is being used, so there is that. However, looking at it now, given that there is an explicit setting in the config to request scattered mode, I think you may be right and that we should error out here if scattered mode is needed and not set. It could help prevent unexpected problems with these drivers. > > 2) Second question is about the "/* It adds dual VLAN length for supporting > dual VLAN */" bit... > > As I understand it, dev_conf.rxmode.max_rx_pkt_len is supposed to be set to > the max frame size you support (although it says it's only used if jumbo > frame is enabled). That same value is generally used when calculating the > size that mbuf elements should be created at. > > The description for the data_room_size parameter of > rte_pktmbuf_pool_create(): > > "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM." > > > If I support a max frame size of 9216 bytes (exactly a 1K multiple to make > the NIC happy), then max_rx_pkt_len is going to be 9216 and data_room_size > will be 9216 + RTE_PKTMBUF_HEADROOM. > > ixgbe_dev_rx_init() will calculate normalize that back to 9216, which will > fail the dual VLAN length check. The really nasty part about that is it has > a side-effect of enabling scattered RX regardless of the fact that I didn't > enable scattered RX in dev_conf.rxmode. > > The code in the e1000 PMD is similar, so nothing unique to ixgbe. > > Is that check correct? It seems wrong to be adding space for q-in-q on top > of your specified max frame size... The issue here is what the correct behaviour needs to be. If we have the user specify the maximum frame size including all vlan tags, then we hit the problem where we have to subtract the VLAN tag sizes when writing the value to the NIC. In that case, we will hit a problem where we get a e.g. 9210 byte frame - to reuse your example - without any VLAN tags, which will be rejected by the hardware as being oversized. If we don't do the subtraction, and we get the same 9210 byte packet with 2 VLAN tags on it, the hardware will accept it and then split it across multiple descriptors because the actual DMA size is 9218 bytes. I'm not sure there is a works-in-all-cases solution here. /Bruce > > Thanks, > Jay
[dpdk-dev] [PATCH 1/1] lib/librte_eal: fix resource leak
On Tue, Apr 19, 2016 at 6:27 PM, Marcin Kerlin
wrote:
> Fix issue reported by Coverity.
>
> Coverity ID 13295, 13296, 13303:
> Resource leak: The system resource will not be reclaimed
> and reused, reducing the future availability of the resource.
> In rte_eal_hugepage_attach: Leak of memory or pointers to system
> resources.
>
> Fixes: af75078fece3 ("first public release")
>
> Signed-off-by: Marcin Kerlin
> ---
> lib/librte_eal/linuxapp/eal/eal_memory.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index 5b9132c..6320aa0 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -1475,13 +1475,17 @@ rte_eal_hugepage_attach(void)
> "and retry running both primary "
> "and secondary processes\n");
> }
> +
> + if (base_addr != MAP_FAILED)
> + munmap((void *)(uintptr_t)base_addr,
> mcfg->memseg[s].len);
> +
What is the point of this casting ?
Idem for the rest of the patch.
I can't see cleanup for previously mapped segments when mapping one fails.
Do we want this cleanup as well ?
CC Sergio.
--
David Marchand
[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build
On Wed, Apr 20, 2016 at 10:51:06AM +0200, Thomas Monjalon wrote: > 2016-04-20 00:14, Harish Patil: > > >2016-03-31 19:15, Rasesh Mody: > > >> --- a/config/common_base > > >> +++ b/config/common_base > > >> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24 > > >> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48 > > > > > >It looks to be some tuning which could be done at runtime. Isn't it? > > > > That?s right. Can you please suggest if there is any better option to make > > it a runtime? There is no PMD API for that. > > There are some devargs for that. > For PCI dev, it can be passed in the whitelist option. > We should remove this limitation by having a devargs API (and command line > options) independent of whitelisting. But back to the original setting. Are these likely to be values that are tunable or need to be tunable by the user? If not, I see little reason to make them run-time configurable - they could be defines inside the driver itself. /Bruce
[dpdk-dev] ixgbe : query regarding your code changes for VF mac add
Hi Ivan,
Thanks for your response.
Let me explain you the issue that we are facing on our virtual router
in VMware environment.
1. We are using ixgbe driver , SRIOV enabled .
root at localhost:~# lspci
"Intel Corporation 82599 Ethernet Controller Virtual Function"
2. "mx86-bgl-1-r1" is our router under testing and R2 is a standard router.
mx86-bgl-1-r1 is connected to R2
mx86-bgl-1-r1 (10.1.1.103)-->R2(10.1.1.101)
2. This time ping test passes
root at mx86-bgl-1-r1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.1.1.103/24;
}
}
}
[edit]
root at mx86-bgl-1-r1#
root at mx86-bgl-1-r1# run ping 10.1.1.101
PING 10.1.1.101 (10.1.1.101): 56 data bytes
64 bytes from 10.1.1.101: icmp_seq=0 ttl=64 time=0.980 ms
64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=1.433 ms
3. Default MAC address of interface ge-0/0/0 is as shown below:
root at mx86-bgl-1-r1# run show interfaces ge-0/0/0 extensive | grep current
Current address: 02:06:0a:0e:ff:f0, Hardware address: 02:06:0a:0e:ff:f0
[edit]
root at mx86-bgl-1-r1#
4. Now I am changing MAC. Ping works this time also
root at mx86-bgl-1-r1# set interfaces ge-0/0/0 mac 02:06:0a:0a:ff:f0
[edit]
root at mx86-bgl-1-r1# commit
commit complete
[edit]
root at mx86-bgl-1-r1# run show interfaces ge-0/0/0 extensive | grep current
Current address: 02:06:0a:0a:ff:f0, Hardware address: 02:06:0a:0e:ff:f0
[edit]
root at mx86-bgl-1-r1# show interfaces
ge-0/0/0 {
mac 02:06:0a:0a:ff:f0;
unit 0 {
family inet {
address 10.1.1.103/24;
}
}
}
[edit]
root at mx86-bgl-1-r1#
root at mx86-bgl-1-r1# run ping 10.1.1.101
PING 10.1.1.101 (10.1.1.101): 56 data bytes
64 bytes from 10.1.1.101: icmp_seq=0 ttl=64 time=1.338 ms
64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=8.832 ms
64 bytes from 10.1.1.101: icmp_seq=2 ttl=64 time=1.292 ms
5. I am deleting the above configured MAC.
In this case newly configured MAC as shown above will be deleted
and Default MAC (02:06:0a:0e:ff:f0)
will be applied. Ping fails at this step. "return statement
added by you is not allowing to configure default MAC.
[edit]
root at mx86-bgl-1-r1# delete interfaces ge-0/0/0 mac
[edit]
root at mx86-bgl-1-r1# commit
commit complete
[edit]
root at mx86-bgl-1-r1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.1.1.103/24;
}
}
}
[edit]
root at mx86-bgl-1-r1# run show interfaces ge-0/0/0 extensive | grep
current // Displays value from router's local database not from
NIC.
Current address: 02:06:0a:0e:ff:f0, Hardware address: 02:06:0a:0e:ff:f0
[edit]
root at mx86-bgl-1-r1# run ping 10.1.1.101
PING 10.1.1.101 (10.1.1.101): 56 data bytes
^C
2 packets transmitted, 0 packets received, 100% packet loss
[edit]
root at mx86-bgl-1-r1#
7. LOGs:(I have added a debug log just before the return statement
that you place)
Log o/p in failure case
Santosh ixgbevf_add_mac_addr returning
code changes:
-
ixgbevf_add_mac_addr() {
...
if (memcmp(hw->mac.perm_addr, mac_addr, sizeof(struct ether_addr)) == 0) {
PMD_DRV_LOG(DEBUG, "Existing MAC \n");
printf("Santosh %s returning \n",__FUNCTION__);
return;
}
8. If I remove the above "return" statement, build the driver, loaded
in router and repeat the steps-2 to steps-5 of MAC add and MAC delete
on our router then ping passes.
root at mx86-bgl-1-r1# run ping 10.1.1.101
PING 10.1.1.101 (10.1.1.101): 56 data bytes
64 bytes from 10.1.1.101: icmp_seq=0 ttl=64 time=2.356 ms
64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=1.415 ms
64 bytes from 10.1.1.101: icmp_seq=2 ttl=64 time=1.226 ms
^C
--- 10.1.1.101 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.226/1.666/2.356/0.494 ms
9. Please let me know whether is it fine to remove that return
statement added by you in "ixgbevf_add_mac_addr" ?
Thanks & Regards,
Santosh
On Wed, Apr 20, 2016 at 3:31 AM, Ivan Boule wrote:
> Hi Santosh,
>
> I do not get exactly what you attempt to do on a VF.
> Are you first deleting the so-called permanent MAC address by a call to the
> function ixgbevf_remove_mac_addr() ? This operation is not allowed.
> Can you explain exactly the sequence of operations that are done, so that I
> can understand how the test (memcmp(hw->mac.perm_addr, mac_addr,
> sizeof(struct ether_addr)) == 0) in the function ixgbevf_add_mac_addr()
> prevents them to be successfully performed.
>
> Ivan
>
> PS : please, can you CC your emails to dev at dpdk.org
>
>
> 2016-04-19 17:01 GMT+02:00 santosh :
>>
>> Hi Ivan,
>>
>> Your following code changes causing issue in Vmware environment.
>>
>> --- ---
>> --
>> + /*
>> + * On a 82599 VF, adding again the same MAC addr is not an idempotent
>> + * operation. Tra
[dpdk-dev] Couple of PMD questions
Hi Jay, On Tue, Apr 19, 2016 at 10:16 PM, Jay Rolette wrote: > Should the driver error out in that case instead of only "sort of" working? +1, we hit the same issue. Error or log message would help. > If I support a max frame size of 9216 bytes (exactly a 1K multiple to make > the NIC happy), then max_rx_pkt_len is going to be 9216 and data_room_size > will be 9216 + RTE_PKTMBUF_HEADROOM. Try to set max_rx_pkt_len <= 9K - 8 and mempool element size to 9K + headroom + size of structures. > Is that check correct? Datasheet says: The MFS does not include the 4 bytes of the VLAN header. Packets with VLAN header can be as large as MFS + 4. When double VLAN is enabled, the device adds 8 to the MFS for any packets. Regards, Andriy
[dpdk-dev] [PATCH v2] ethdev: remove deprecated statistics
Some statistics were deprecated since release 2.1 (49f386542af4).
The last deprecated counter to be used was imcasts.
The VF loopback statistics are also removed as they are used only
in igb and duplicated in extended statistics.
The new counters should be added to extended statistics.
Signed-off-by: Thomas Monjalon
---
v2:
- remove VF loopback stats
- remove comment in ethtool example
doc/guides/rel_notes/deprecation.rst | 4
doc/guides/rel_notes/release_16_07.rst | 6 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 1 -
drivers/net/cxgbe/cxgbe_ethdev.c | 1 -
drivers/net/e1000/igb_ethdev.c | 5 -
drivers/net/ena/ena_ethdev.c | 2 --
drivers/net/ena/ena_ethdev.h | 1 -
drivers/net/enic/enic_main.c | 1 -
drivers/net/i40e/i40e_ethdev.c | 1 -
drivers/net/ixgbe/ixgbe_ethdev.c | 4
drivers/net/nfp/nfp_net.c | 18 --
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 -
examples/ethtool/ethtool-app/ethapp.c | 1 -
lib/librte_ether/Makefile | 2 +-
lib/librte_ether/rte_ethdev.h | 26 --
15 files changed, 6 insertions(+), 68 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index c78cde7..fffe9c7 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -26,10 +26,6 @@ Deprecation Notices
rte_pci_device. The release 16.04 does not contain these ABI changes, but
release 16.07 will.
-* The following fields have been deprecated in rte_eth_stats:
- ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
- tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
-
* The xstats API and rte_eth_xstats struct will be changed to allow retrieval
of values without any string copies or parsing.
No backwards compatibility is planned, as it would require code duplication
diff --git a/doc/guides/rel_notes/release_16_07.rst
b/doc/guides/rel_notes/release_16_07.rst
index 001888f..83c841b 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -86,6 +86,10 @@ This section should contain API changes. Sample format:
* Add a short 1-2 sentence description of the API change. Use fixed width
quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past
tense.
+* The following counters are removed from ``rte_eth_stats`` structure:
+ ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
+ tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff.
+
ABI Changes
---
@@ -107,7 +111,7 @@ The libraries prepended with a plus sign were incremented
in this version.
.. code-block:: diff
- libethdev.so.3
+ + libethdev.so.4
librte_acl.so.2
librte_cfgfile.so.2
librte_cmdline.so.2
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 54788cf..c897146 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1836,7 +1836,6 @@ bond_ethdev_stats_get(struct rte_eth_dev *dev, struct
rte_eth_stats *stats)
stats->imissed += slave_stats.imissed;
stats->ierrors += slave_stats.ierrors;
stats->oerrors += slave_stats.oerrors;
- stats->imcasts += slave_stats.imcasts;
stats->rx_nombuf += slave_stats.rx_nombuf;
for (j = 0; j < RTE_ETHDEV_QUEUE_STAT_CNTRS; j++) {
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index bb134e5..04eddaf 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -656,7 +656,6 @@ static void cxgbe_dev_stats_get(struct rte_eth_dev *eth_dev,
/* RX Stats */
eth_stats->ipackets = ps.rx_frames;
eth_stats->ibytes = ps.rx_octets;
- eth_stats->imcasts = ps.rx_mcast_frames;
eth_stats->imissed = ps.rx_ovflow0 + ps.rx_ovflow1 +
ps.rx_ovflow2 + ps.rx_ovflow3 +
ps.rx_trunc0 + ps.rx_trunc1 +
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index e0053fe..f0921ee 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1805,11 +1805,6 @@ eth_igbvf_stats_get(struct rte_eth_dev *dev, struct
rte_eth_stats *rte_stats)
rte_stats->ibytes = hw_stats->gorc;
rte_stats->opackets = hw_stats->gptc;
rte_stats->obytes = hw_stats->gotc;
- rte_stats->imcasts = hw_stats->mprc;
- rte_stats->ilbpackets = hw_stats->gprlbc;
- rte_stats->ilbbytes = hw_stats->gorlbc;
- rte_stats->olbpackets = hw_stats->gptlbc;
- rte_stats->olbbytes = hw_stats->gotlbc;
}
static void
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 02af67a..e157587 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -605,7 +605,6 @@ static void ena_
[dpdk-dev] [PATCH] port: bump ABI for pcap file support
> > Support of PCAP file has been added to rte_port in release 16.04 > > as NEXT_ABI. It is in the standard ABI of the release 16.07. > > > > Signed-off-by: Thomas Monjalon > > Acked-by: Cristian Dumitrescu Applied
[dpdk-dev] [PATCH 3/3 v7] i40e: Add global reset support for i40e
Hi, zhe
Beside hein's global reset concern. I have another comment:
Do you copy the following codes from i40e kernel driver? Have
You done the Protext IP scan for it?
Just let you know that linux kernel is GPL liscense, we can
Not just copy code from it without any modification.
Thanks
Jingjing
> +
> +/**
> + * i40e_do_reset - Start a PF or Core Reset sequence
> + * @pf: board private structure
> + * @reset_flags: which reset is requested
> + *
> + * The essential difference in resets is that the PF Reset
> + * doesn't clear the packet buffers, doesn't reset the PE
> + * firmware, and doesn't bother the other PFs on the chip.
> + **/
> +static void i40e_do_reset(struct i40e_hw *hw, u32 reset_flags) {
> + u32 val;
> +
> + /* do the biggest reset indicated */
> + if (reset_flags & BIT_ULL(__I40E_GLOBAL_RESET_REQUESTED)) {
> + /* Request a Global Reset
> + *
> + * This will start the chip's countdown to the actual full
> + * chip reset event, and a warning interrupt to be sent
> + * to all PFs, including the requestor. Our handler
> + * for the warning interrupt will deal with the shutdown
> + * and recovery of the switch setup.
> + */
> + PMD_INIT_LOG(NOTICE, "GlobalR requested\n");
> + val = rd32(hw, I40E_GLGEN_RTRIG);
> + val |= I40E_GLGEN_RTRIG_GLOBR_MASK;
> + wr32(hw, I40E_GLGEN_RTRIG, val);
> + }
> + /* other reset operations are not supported now */ }
> diff --git a/drivers/net/i40e/i40e_ethdev.h
> b/drivers/net/i40e/i40e_ethdev.h index 09fb6e2..f2a2fcc 100644
> --- a/drivers/net/i40e/i40e_ethdev.h
> +++ b/drivers/net/i40e/i40e_ethdev.h
> @@ -108,6 +108,36 @@ enum i40e_flxpld_layer_idx {
> I40E_FLXPLD_L4_IDX= 2,
> I40E_MAX_FLXPLD_LAYER = 3,
> };
> +
> +/* driver state flags */
> +enum i40e_state_t {
> + __I40E_TESTING,
> + __I40E_CONFIG_BUSY,
> + __I40E_CONFIG_DONE,
> + __I40E_DOWN,
> + __I40E_NEEDS_RESTART,
> + __I40E_SERVICE_SCHED,
> + __I40E_ADMINQ_EVENT_PENDING,
> + __I40E_MDD_EVENT_PENDING,
> + __I40E_VFLR_EVENT_PENDING,
> + __I40E_RESET_RECOVERY_PENDING,
> + __I40E_RESET_INTR_RECEIVED,
> + __I40E_REINIT_REQUESTED,
> + __I40E_PF_RESET_REQUESTED,
> + __I40E_CORE_RESET_REQUESTED,
> + __I40E_GLOBAL_RESET_REQUESTED,
> + __I40E_EMP_RESET_REQUESTED,
> + __I40E_EMP_RESET_INTR_RECEIVED,
> + __I40E_FILTER_OVERFLOW_PROMISC,
> + __I40E_SUSPENDED,
> + __I40E_BAD_EEPROM,
> + __I40E_DEBUG_MODE,
> + __I40E_DOWN_REQUESTED,
> + __I40E_FD_FLUSH_REQUESTED,
> + __I40E_RESET_FAILED,
> + __I40E_PORT_TX_SUSPENDED,
> + __I40E_VF_DISABLE,
> +};
> #define I40E_MAX_FLXPLD_FIED3 /* max number of flex payload fields
> */
> #define I40E_FDIR_BITMASK_NUM_WORD 2 /* max number of bitmask
> words */ #define I40E_FDIR_MAX_FLEXWORD_NUM 8 /* max number of
> flexpayload words */
> --
> 2.1.4
[dpdk-dev] Recall: [PATCH 3/3 v7] i40e: Add global reset support for i40e
Wu, Jingjing would like to recall the message, "[dpdk-dev][PATCH 3/3 v7] i40e: Add global reset support for i40e".
[dpdk-dev] [PATCH] pci: remove deprecated specific config
> >> The driver i40e was using a specific PCI config before the release 16.04. > >> From 16.04, it is always enabled in i40e (commit 56465cfaf). > >> The API has been deprecated in the commit 68f77593823cab. > >> The igb_uio implementation has been deprecated in commit b7cf8e155. > >> The config helper - through igb_uio sysfs entries - is now removed. > >> > >> Signed-off-by: Thomas Monjalon > > Acked-by: Helin Zhang > > Thanks. > Acked-by: David Marchand Applied
[dpdk-dev] [RFC] examples: remove l3fwd-vf example
2015-08-04 17:12, Ananyev, Konstantin: > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael > > Actually, l3fwd works fine with fm10k vf. > > > > I don't know what's the exact reason of l3fwd-vf still in DPDK, > > at least we could make full support for vf in l3fwd instead of another > > sample with most code are the same compare with l3fwd. > > Right now, l3fwd is not able to work properly for cases where number of > forwarding lcores > exceeds number of tx queues on any active port. > As an example: > 2 forwarding lcores and a port with just 1 TX queue (e1000 legacy device). > > To make l3fwd work for such cases you need to add some sort of > synchronisation on TX path. > Which means one of 2 ways: > either introduce different TX path into l3fwd (one with sync if > legacy/virual device is used, another without) > and select it on process startup/config phase, > or sync overhead for fastpath. Any news about removing l3fwd-vf example? l3fwd has been reworked but l3fwd-power, l3fwd-vf and l3fwd-thread are still based on the old l3fwd with APP_LOOKUP_METHOD compile-time flag.
[dpdk-dev] [PATCH v2] ethdev: remove deprecated statistics
On 20/04/2016 10:47, Thomas Monjalon wrote: > Some statistics were deprecated since release 2.1 (49f386542af4). > The last deprecated counter to be used was imcasts. > > The VF loopback statistics are also removed as they are used only > in igb and duplicated in extended statistics. > > The new counters should be added to extended statistics. > > Signed-off-by: Thomas Monjalon Acked-by: Remy Horton
[dpdk-dev] [PATCH v3 3/7] drivers/net/bnxt new driver for Broadcom bnxt
On Tue, Apr 19, 2016 at 01:51:32PM -0700, Stephen Hurd wrote: > On Tue, Apr 19, 2016 at 7:19 AM, Bruce Richardson < > bruce.richardson at intel.com> wrote: > > > On Fri, Mar 04, 2016 at 01:05:24PM -0800, Stephen Hurd wrote: > > > New driver for Broadcom bnxt (NexXtreme C-series) devices. > > > > This seems a single huge commit. Can this be split up into separate commits > > with self-contained changes in each one, e.g. a feature per commit, > > starting > > with basic init, then RX and TX etc. etc.? > > > > I suppose it could, I'm not sure what the value of that approach would be > though... it would just be a long process of copy/paste/commit/repeat. > Internally, it was developed as a port/rewrite of another driver, so we > don't actually have history without a large commit. > > Assuming each individual commit needs to be buildable, this will end up > burning a lot of time, and I doubt each separate commit could be reasonably > tested. > > It's not for testing, more for code review and to help understand the code [though as you say, we do need to ensure that each commit doesn't actually break the build]. Right now, the driver code goes in as a single commit - which makes it a hard enough task to review and see what is in there. One suggestion that hopefully wouldn't be too much work might be to split the code up into: basic device init code, RX and TX functions, and then any additional features based on top of that [ideally one patch per added feature]. Regards, /Bruce
[dpdk-dev] [RFC] examples: remove l3fwd-vf example
Hi Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, April 20, 2016 11:47 AM > To: Ananyev, Konstantin > Cc: Qiu, Michael; Zhang, Helin; Liu, Yong; Cao, Waterman; dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC] examples: remove l3fwd-vf example > > 2015-08-04 17:12, Ananyev, Konstantin: > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael > > > Actually, l3fwd works fine with fm10k vf. > > > > > > I don't know what's the exact reason of l3fwd-vf still in DPDK, > > > at least we could make full support for vf in l3fwd instead of another > > > sample with most code are the same compare with l3fwd. > > > > Right now, l3fwd is not able to work properly for cases where number of > > forwarding lcores > > exceeds number of tx queues on any active port. > > As an example: > > 2 forwarding lcores and a port with just 1 TX queue (e1000 legacy device). > > > > To make l3fwd work for such cases you need to add some sort of > > synchronisation on TX path. > > Which means one of 2 ways: > > either introduce different TX path into l3fwd (one with sync if > > legacy/virual device is used, another without) > > and select it on process startup/config phase, > > or sync overhead for fastpath. > > Any news about removing l3fwd-vf example? > > l3fwd has been reworked but l3fwd-power, l3fwd-vf and l3fwd-thread are > still based on the old l3fwd with APP_LOOKUP_METHOD compile-time flag. As far as I know, no-one from Intel side is working on it right now. Konstantin
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
Following discussions with Jan [1] and some cleanup I started on pci code, here is a patchset that reworks pdev drivers registration and hotplug api. The structures changes mentioned in [1] are still to be done, but at least, I think we are one step closer to it. Before this patchset, rte_driver .init semantics differed whether it concerned a pdev or a vdev driver: - for vdev, it actually meant that a devargs is given to the driver so that it creates ethdev / crypto objects, so it was a probing action - for pdev, it only registered the driver triggering no ethdev / crypto objects >From my pov, eal hotplug api introduced in this patchset still needs more work so that it does not need to know about devargs. So a new devargs api is needed. Changes since v1: - rebased on HEAD, new drivers should be okay - patches have been split into smaller pieces - RTE_INIT macro has been added, but in the end, I am not sure it is useful - device type has been removed from ethdev, as it was used only by hotplug - getting rid of pmd type in eal patch (patch 5 of initial series) has been dropped for now, we can do this once vdev drivers have been converted [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html Regards, -- David Marchand David Marchand (17): pci: no need for dynamic tailq init crypto: no need for a crypto pmd type drivers: align pci driver definitions eal: remove duplicate function declaration eal: introduce init macros crypto: export init/uninit common wrappers for pci drivers ethdev: export init/uninit common wrappers for pci drivers drivers: convert all pdev drivers as pci drivers crypto: get rid of crypto driver register callback ethdev: get rid of eth driver register callback eal/linux: move back interrupt thread init before setting affinity pci: add a helper for device name pci: add a helper to update a device ethdev: do not scan all pci devices on attach eal: add hotplug operations for pci and vdev ethdev: convert to eal hotplug ethdev: get rid of device type app/test/virtual_pmd.c | 2 +- drivers/crypto/qat/rte_qat_cryptodev.c | 18 +- drivers/net/af_packet/rte_eth_af_packet.c | 2 +- drivers/net/bnx2x/bnx2x_ethdev.c| 35 +-- drivers/net/bonding/rte_eth_bond_api.c | 2 +- drivers/net/cxgbe/cxgbe_ethdev.c| 24 +- drivers/net/cxgbe/cxgbe_main.c | 2 +- drivers/net/e1000/em_ethdev.c | 16 +- drivers/net/e1000/igb_ethdev.c | 40 +-- drivers/net/ena/ena_ethdev.c| 20 +- drivers/net/enic/enic_ethdev.c | 23 +- drivers/net/fm10k/fm10k_ethdev.c| 23 +- drivers/net/i40e/i40e_ethdev.c | 26 +- drivers/net/i40e/i40e_ethdev_vf.c | 25 +- drivers/net/ixgbe/ixgbe_ethdev.c| 47 +--- drivers/net/mlx4/mlx4.c | 22 +- drivers/net/mlx5/mlx5.c | 21 +- drivers/net/mpipe/mpipe_tilegx.c| 2 +- drivers/net/nfp/nfp_net.c | 23 +- drivers/net/null/rte_eth_null.c | 2 +- drivers/net/pcap/rte_eth_pcap.c | 2 +- drivers/net/ring/rte_eth_ring.c | 2 +- drivers/net/szedata2/rte_eth_szedata2.c | 25 +- drivers/net/vhost/rte_eth_vhost.c | 2 +- drivers/net/virtio/virtio_ethdev.c | 26 +- drivers/net/vmxnet3/vmxnet3_ethdev.c| 23 +- drivers/net/xenvirt/rte_eth_xenvirt.c | 2 +- examples/ip_pipeline/init.c | 22 -- lib/librte_cryptodev/rte_cryptodev.c| 67 + lib/librte_cryptodev/rte_cryptodev.h| 2 - lib/librte_cryptodev/rte_cryptodev_pmd.h| 45 +--- lib/librte_cryptodev/rte_cryptodev_version.map | 9 +- lib/librte_eal/bsdapp/eal/eal_pci.c | 52 +++- lib/librte_eal/bsdapp/eal/rte_eal_version.map | 8 + lib/librte_eal/common/eal_common_dev.c | 39 +++ lib/librte_eal/common/eal_common_pci.c | 17 +- lib/librte_eal/common/eal_private.h | 20 +- lib/librte_eal/common/include/rte_dev.h | 29 ++- lib/librte_eal/common/include/rte_eal.h | 3 + lib/librte_eal/common/include/rte_pci.h | 32 +++ lib/librte_eal/common/include/rte_tailq.h | 4 +- lib/librte_eal/linuxapp/eal/eal.c | 7 +- lib/librte_eal/linuxapp/eal/eal_pci.c | 16 +- lib/librte_eal/linuxapp/eal/rte_eal_version.map | 8 + lib/librte_ether/rte_ethdev.c | 316 lib/librte_ether/rte_ethdev.h | 40 ++- lib/librte_ether/rte_ether_version.map | 9 +- 47 files changed, 392 insertions(+), 810 deletions(-) -- 1.9.1
[dpdk-dev] [PATCH v2 01/17] pci: no need for dynamic tailq init
These lists can be initialized once and for all at build time.
With this, those lists are only manipulated in a common place
(and we could even make them private).
A nice side effect is that pci drivers can now register in constructors.
Signed-off-by: David Marchand
Reviewed-by: Jan Viktorin
---
lib/librte_eal/bsdapp/eal/eal_pci.c| 3 ---
lib/librte_eal/common/eal_common_pci.c | 6 --
lib/librte_eal/linuxapp/eal/eal_pci.c | 3 ---
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 2d16d78..cd8e8d3 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -618,9 +618,6 @@ rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
int
rte_eal_pci_init(void)
{
- TAILQ_INIT(&pci_driver_list);
- TAILQ_INIT(&pci_device_list);
-
/* for debug purposes, PCI can be disabled */
if (internal_config.no_pci)
return 0;
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 40f4922..80d8ec6 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -82,8 +82,10 @@
#include "eal_private.h"
-struct pci_driver_list pci_driver_list;
-struct pci_device_list pci_device_list;
+struct pci_driver_list pci_driver_list =
+ TAILQ_HEAD_INITIALIZER(pci_driver_list);
+struct pci_device_list pci_device_list =
+ TAILQ_HEAD_INITIALIZER(pci_device_list);
static struct rte_devargs *pci_devargs_lookup(struct rte_pci_device *dev)
{
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index dbf12a8..3fc82b0 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -731,9 +731,6 @@ rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
int
rte_eal_pci_init(void)
{
- TAILQ_INIT(&pci_driver_list);
- TAILQ_INIT(&pci_device_list);
-
/* for debug purposes, PCI can be disabled */
if (internal_config.no_pci)
return 0;
--
1.9.1
[dpdk-dev] [PATCH v2 02/17] crypto: no need for a crypto pmd type
This information is not used and just adds noise.
Signed-off-by: David Marchand
---
lib/librte_cryptodev/rte_cryptodev.c | 8 +++-
lib/librte_cryptodev/rte_cryptodev.h | 2 --
lib/librte_cryptodev/rte_cryptodev_pmd.h | 3 +--
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/lib/librte_cryptodev/rte_cryptodev.c
b/lib/librte_cryptodev/rte_cryptodev.c
index aa4ea42..bf35df0 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -230,7 +230,7 @@ rte_cryptodev_find_free_device_index(void)
}
struct rte_cryptodev *
-rte_cryptodev_pmd_allocate(const char *name, enum pmd_type type, int socket_id)
+rte_cryptodev_pmd_allocate(const char *name, int socket_id)
{
struct rte_cryptodev *cryptodev;
uint8_t dev_id;
@@ -269,7 +269,6 @@ rte_cryptodev_pmd_allocate(const char *name, enum pmd_type
type, int socket_id)
cryptodev->data->dev_started = 0;
cryptodev->attached = RTE_CRYPTODEV_ATTACHED;
- cryptodev->pmd_type = type;
cryptodev_globals.nb_devs++;
}
@@ -318,7 +317,7 @@ rte_cryptodev_pmd_virtual_dev_init(const char *name, size_t
dev_private_size,
struct rte_cryptodev *cryptodev;
/* allocate device structure */
- cryptodev = rte_cryptodev_pmd_allocate(name, PMD_VDEV, socket_id);
+ cryptodev = rte_cryptodev_pmd_allocate(name, socket_id);
if (cryptodev == NULL)
return NULL;
@@ -360,8 +359,7 @@ rte_cryptodev_init(struct rte_pci_driver *pci_drv,
rte_cryptodev_create_unique_device_name(cryptodev_name,
sizeof(cryptodev_name), pci_dev);
- cryptodev = rte_cryptodev_pmd_allocate(cryptodev_name, PMD_PDEV,
- rte_socket_id());
+ cryptodev = rte_cryptodev_pmd_allocate(cryptodev_name, rte_socket_id());
if (cryptodev == NULL)
return -ENOMEM;
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index d47f1e8..2d0b809 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -697,8 +697,6 @@ struct rte_cryptodev {
enum rte_cryptodev_type dev_type;
/**< Crypto device type */
- enum pmd_type pmd_type;
- /**< PMD type - PDEV / VDEV */
struct rte_cryptodev_cb_list link_intr_cbs;
/**< User application callback for interrupts if present */
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 7d049ea..c977c61 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -454,13 +454,12 @@ struct rte_cryptodev_ops {
* to that slot for the driver to use.
*
* @param nameUnique identifier name for each device
- * @param typeDevice type of this Crypto device
* @param socket_id Socket to allocate resources on.
* @return
* - Slot in the rte_dev_devices array for a new device;
*/
struct rte_cryptodev *
-rte_cryptodev_pmd_allocate(const char *name, enum pmd_type type, int
socket_id);
+rte_cryptodev_pmd_allocate(const char *name, int socket_id);
/**
* Creates a new virtual crypto device and returns the pointer
--
1.9.1
[dpdk-dev] [PATCH v2 03/17] drivers: align pci driver definitions
Pure coding style, but it might make it easier later if we want to move
fields in rte_cryptodev_driver and eth_driver structures.
Signed-off-by: David Marchand
---
drivers/crypto/qat/rte_qat_cryptodev.c | 2 +-
drivers/net/ena/ena_ethdev.c | 2 +-
drivers/net/nfp/nfp_net.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c
b/drivers/crypto/qat/rte_qat_cryptodev.c
index a7912f5..08496ab 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -116,7 +116,7 @@ crypto_qat_dev_init(__attribute__((unused)) struct
rte_cryptodev_driver *crypto_
}
static struct rte_cryptodev_driver rte_qat_pmd = {
- {
+ .pci_drv = {
.name = "rte_qat_pmd",
.id_table = pci_id_qat_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 02af67a..fbc96ae 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1429,7 +1429,7 @@ static uint16_t eth_ena_xmit_pkts(void *tx_queue, struct
rte_mbuf **tx_pkts,
}
static struct eth_driver rte_ena_pmd = {
- {
+ .pci_drv = {
.name = "rte_ena_pmd",
.id_table = pci_id_ena_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index bcf5fa9..fb23b74 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2474,7 +2474,7 @@ static struct rte_pci_id pci_id_nfp_net_map[] = {
};
static struct eth_driver rte_nfp_net_pmd = {
- {
+ .pci_drv = {
.name = "rte_nfp_net_pmd",
.id_table = pci_id_nfp_net_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
--
1.9.1
[dpdk-dev] [PATCH v2 04/17] eal: remove duplicate function declaration
rte_eal_dev_init is declared in both eal_private.h and rte_dev.h since its
introduction.
This function has been exported in ABI, so remove it from eal_private.h
Fixes: e57f20e05177 ("eal: make vdev init path generic for both virtual and pci
devices")
Signed-off-by: David Marchand
---
lib/librte_eal/common/eal_private.h | 7 ---
lib/librte_eal/linuxapp/eal/eal.c | 1 +
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/lib/librte_eal/common/eal_private.h
b/lib/librte_eal/common/eal_private.h
index 2342fa1..855fd25 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -262,13 +262,6 @@ int rte_eal_intr_init(void);
int rte_eal_alarm_init(void);
/**
- * This function initialises any virtual devices
- *
- * This function is private to the EAL.
- */
-int rte_eal_dev_init(void);
-
-/**
* Function is to check if the kernel module(like, vfio, vfio_iommu_type1,
* etc.) loaded.
*
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 8aafd51..f26f8d3 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -70,6 +70,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
1.9.1
[dpdk-dev] [PATCH v2 05/17] eal: introduce init macros
Introduce a RTE_INIT macro used to mark an init function as a constructor.
Current eal macros have been converted to use this (no functional impact).
RTE_EAL_PCI_REGISTER is added as a helper for pci drivers.
Suggested-by: Jan Viktorin
Signed-off-by: David Marchand
---
lib/librte_eal/common/include/rte_dev.h | 4 ++--
lib/librte_eal/common/include/rte_eal.h | 3 +++
lib/librte_eal/common/include/rte_pci.h | 7 +++
lib/librte_eal/common/include/rte_tailq.h | 4 ++--
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index f1b5507..85e48f2 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -179,8 +179,8 @@ int rte_eal_vdev_init(const char *name, const char *args);
int rte_eal_vdev_uninit(const char *name);
#define PMD_REGISTER_DRIVER(d)\
-void devinitfn_ ##d(void);\
-void __attribute__((constructor, used)) devinitfn_ ##d(void)\
+RTE_INIT(devinitfn_ ##d);\
+static void devinitfn_ ##d(void)\
{\
rte_eal_driver_register(&d);\
}
diff --git a/lib/librte_eal/common/include/rte_eal.h
b/lib/librte_eal/common/include/rte_eal.h
index a71d6f5..186f3c6 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -252,6 +252,9 @@ static inline int rte_gettid(void)
return RTE_PER_LCORE(_thread_id);
}
+#define RTE_INIT(func) \
+static void __attribute__((constructor, used)) func(void)
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index e692094..f99b33a 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -471,6 +471,13 @@ void rte_eal_pci_dump(FILE *f);
*/
void rte_eal_pci_register(struct rte_pci_driver *driver);
+#define RTE_EAL_PCI_REGISTER(name, d) \
+RTE_INIT(pciinitfn_ ##name); \
+static void pciinitfn_ ##name(void) \
+{ \
+ rte_eal_pci_register(&d); \
+}
+
/**
* Unregister a PCI driver.
*
diff --git a/lib/librte_eal/common/include/rte_tailq.h
b/lib/librte_eal/common/include/rte_tailq.h
index 4a686e6..71ed3bb 100644
--- a/lib/librte_eal/common/include/rte_tailq.h
+++ b/lib/librte_eal/common/include/rte_tailq.h
@@ -148,8 +148,8 @@ struct rte_tailq_head *rte_eal_tailq_lookup(const char
*name);
int rte_eal_tailq_register(struct rte_tailq_elem *t);
#define EAL_REGISTER_TAILQ(t) \
-void tailqinitfn_ ##t(void); \
-void __attribute__((constructor, used)) tailqinitfn_ ##t(void) \
+RTE_INIT(tailqinitfn_ ##t); \
+static void tailqinitfn_ ##t(void) \
{ \
if (rte_eal_tailq_register(&t) < 0) \
rte_panic("Cannot initialize tailq: %s\n", t.name); \
--
1.9.1
[dpdk-dev] [PATCH v2 06/17] crypto: export init/uninit common wrappers for pci drivers
Preparing for getting rid of rte_cryptodev_driver, here are two wrappers
that can be used by pci drivers that assume a 1 to 1 association between
pci resource and upper interface.
Signed-off-by: David Marchand
---
lib/librte_cryptodev/rte_cryptodev.c | 16
lib/librte_cryptodev/rte_cryptodev_pmd.h | 12
lib/librte_cryptodev/rte_cryptodev_version.map | 8
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/lib/librte_cryptodev/rte_cryptodev.c
b/lib/librte_cryptodev/rte_cryptodev.c
index bf35df0..19a9939 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -340,9 +340,9 @@ rte_cryptodev_pmd_virtual_dev_init(const char *name, size_t
dev_private_size,
return cryptodev;
}
-static int
-rte_cryptodev_init(struct rte_pci_driver *pci_drv,
- struct rte_pci_device *pci_dev)
+int
+rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
+ struct rte_pci_device *pci_dev)
{
struct rte_cryptodev_driver *cryptodrv;
struct rte_cryptodev *cryptodev;
@@ -401,8 +401,8 @@ rte_cryptodev_init(struct rte_pci_driver *pci_drv,
return -ENXIO;
}
-static int
-rte_cryptodev_uninit(struct rte_pci_device *pci_dev)
+int
+rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
{
const struct rte_cryptodev_driver *cryptodrv;
struct rte_cryptodev *cryptodev;
@@ -450,15 +450,15 @@ rte_cryptodev_pmd_driver_register(struct
rte_cryptodev_driver *cryptodrv,
{
/* Call crypto device initialization directly if device is virtual */
if (type == PMD_VDEV)
- return rte_cryptodev_init((struct rte_pci_driver *)cryptodrv,
+ return rte_cryptodev_pci_probe((struct rte_pci_driver
*)cryptodrv,
NULL);
/*
* Register PCI driver for physical device intialisation during
* PCI probing
*/
- cryptodrv->pci_drv.devinit = rte_cryptodev_init;
- cryptodrv->pci_drv.devuninit = rte_cryptodev_uninit;
+ cryptodrv->pci_drv.devinit = rte_cryptodev_pci_probe;
+ cryptodrv->pci_drv.devuninit = rte_cryptodev_pci_remove;
rte_eal_pci_register(&cryptodrv->pci_drv);
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index c977c61..3fb7c7c 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -534,6 +534,18 @@ rte_cryptodev_pmd_driver_register(struct
rte_cryptodev_driver *crypto_drv,
void rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
enum rte_cryptodev_event_type event);
+/**
+ * Wrapper for use by pci drivers as a .devinit function to attach to a crypto
+ * interface.
+ */
+int rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
+ struct rte_pci_device *pci_dev);
+
+/**
+ * Wrapper for use by pci drivers as a .devuninit function to detach a crypto
+ * interface.
+ */
+int rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev);
#ifdef __cplusplus
}
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map
b/lib/librte_cryptodev/rte_cryptodev_version.map
index 41004e1..8d0edfb 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -32,3 +32,11 @@ DPDK_16.04 {
local: *;
};
+
+DPDK_16.07 {
+ global:
+
+ rte_cryptodev_pci_probe;
+ rte_cryptodev_pci_remove;
+
+} DPDK_16.04;
--
1.9.1
[dpdk-dev] [PATCH v2 07/17] ethdev: export init/uninit common wrappers for pci drivers
Preparing for getting rid of eth_drv, here are two wrappers that can be
used by pci drivers that assume a 1 to 1 association between pci resource and
upper interface.
Signed-off-by: David Marchand
---
lib/librte_ether/rte_ethdev.c | 14 +++---
lib/librte_ether/rte_ethdev.h | 13 +
lib/librte_ether/rte_ether_version.map | 8
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a31018e..7b908a7 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -239,9 +239,9 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
return 0;
}
-static int
-rte_eth_dev_init(struct rte_pci_driver *pci_drv,
-struct rte_pci_device *pci_dev)
+int
+rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
+ struct rte_pci_device *pci_dev)
{
struct eth_driver*eth_drv;
struct rte_eth_dev *eth_dev;
@@ -293,8 +293,8 @@ rte_eth_dev_init(struct rte_pci_driver *pci_drv,
return diag;
}
-static int
-rte_eth_dev_uninit(struct rte_pci_device *pci_dev)
+int
+rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
{
const struct eth_driver *eth_drv;
struct rte_eth_dev *eth_dev;
@@ -351,8 +351,8 @@ rte_eth_dev_uninit(struct rte_pci_device *pci_dev)
void
rte_eth_driver_register(struct eth_driver *eth_drv)
{
- eth_drv->pci_drv.devinit = rte_eth_dev_init;
- eth_drv->pci_drv.devuninit = rte_eth_dev_uninit;
+ eth_drv->pci_drv.devinit = rte_eth_dev_pci_probe;
+ eth_drv->pci_drv.devuninit = rte_eth_dev_pci_remove;
rte_eal_pci_register(ð_drv->pci_drv);
}
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 022733e..7a7a69e 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -4279,6 +4279,19 @@ rte_eth_dev_l2_tunnel_offload_set(uint8_t port_id,
uint32_t mask,
uint8_t en);
+/**
+ * Wrapper for use by pci drivers as a .devinit function to attach to a ethdev
+ * interface.
+ */
+int rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
+ struct rte_pci_device *pci_dev);
+
+/**
+ * Wrapper for use by pci drivers as a .devuninit function to detach a ethdev
+ * interface.
+ */
+int rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_ether/rte_ether_version.map
b/lib/librte_ether/rte_ether_version.map
index 214ecc7..31017d4 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -132,3 +132,11 @@ DPDK_16.04 {
rte_eth_tx_buffer_set_err_callback;
} DPDK_2.2;
+
+DPDK_16.07 {
+ global:
+
+ rte_eth_dev_pci_probe;
+ rte_eth_dev_pci_remove;
+
+} DPDK_16.04;
--
1.9.1
[dpdk-dev] [PATCH v2 08/17] drivers: convert all pdev drivers as pci drivers
Simplify crypto and ethdev pci drivers init by using newly introduced
init macros and helpers.
Those drivers then don't need to register as "rte_driver"s anymore.
virtio and mlx* drivers use the general purpose RTE_INIT macro, as they both
need some special stuff to be done before registering a pci driver.
Signed-off-by: David Marchand
---
drivers/crypto/qat/rte_qat_cryptodev.c | 16 +++
drivers/net/bnx2x/bnx2x_ethdev.c| 35 +---
drivers/net/cxgbe/cxgbe_ethdev.c| 24 +++--
drivers/net/e1000/em_ethdev.c | 16 +++
drivers/net/e1000/igb_ethdev.c | 40 +---
drivers/net/ena/ena_ethdev.c| 18 +++--
drivers/net/enic/enic_ethdev.c | 23 +++-
drivers/net/fm10k/fm10k_ethdev.c| 23 +++-
drivers/net/i40e/i40e_ethdev.c | 26 +++---
drivers/net/i40e/i40e_ethdev_vf.c | 25 +++---
drivers/net/ixgbe/ixgbe_ethdev.c| 47 +
drivers/net/mlx4/mlx4.c | 20 +++---
drivers/net/mlx5/mlx5.c | 19 +++--
drivers/net/nfp/nfp_net.c | 21 +++
drivers/net/szedata2/rte_eth_szedata2.c | 25 +++---
drivers/net/virtio/virtio_ethdev.c | 26 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c| 23 +++-
17 files changed, 68 insertions(+), 359 deletions(-)
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c
b/drivers/crypto/qat/rte_qat_cryptodev.c
index 08496ab..54f0c95 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -120,21 +120,11 @@ static struct rte_cryptodev_driver rte_qat_pmd = {
.name = "rte_qat_pmd",
.id_table = pci_id_qat_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+ .devinit = rte_cryptodev_pci_probe,
+ .devuninit = rte_cryptodev_pci_remove,
},
.cryptodev_init = crypto_qat_dev_init,
.dev_private_size = sizeof(struct qat_pmd_private),
};
-static int
-rte_qat_pmd_init(const char *name __rte_unused, const char *params
__rte_unused)
-{
- PMD_INIT_FUNC_TRACE();
- return rte_cryptodev_pmd_driver_register(&rte_qat_pmd, PMD_PDEV);
-}
-
-static struct rte_driver pmd_qat_drv = {
- .type = PMD_PDEV,
- .init = rte_qat_pmd_init,
-};
-
-PMD_REGISTER_DRIVER(pmd_qat_drv);
+RTE_EAL_PCI_REGISTER(qat, rte_qat_pmd.pci_drv);
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 071b44f..ba194b5 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -506,11 +506,15 @@ static struct eth_driver rte_bnx2x_pmd = {
.name = "rte_bnx2x_pmd",
.id_table = pci_id_bnx2x_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
+ .devinit = rte_eth_dev_pci_probe,
+ .devuninit = rte_eth_dev_pci_remove,
},
.eth_dev_init = eth_bnx2x_dev_init,
.dev_private_size = sizeof(struct bnx2x_softc),
};
+RTE_EAL_PCI_REGISTER(bnx2x, rte_bnx2x_pmd.pci_drv);
+
/*
* virtual function driver struct
*/
@@ -519,36 +523,11 @@ static struct eth_driver rte_bnx2xvf_pmd = {
.name = "rte_bnx2xvf_pmd",
.id_table = pci_id_bnx2xvf_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+ .devinit = rte_eth_dev_pci_probe,
+ .devuninit = rte_eth_dev_pci_remove,
},
.eth_dev_init = eth_bnx2xvf_dev_init,
.dev_private_size = sizeof(struct bnx2x_softc),
};
-static int rte_bnx2x_pmd_init(const char *name __rte_unused, const char
*params __rte_unused)
-{
- PMD_INIT_FUNC_TRACE();
- rte_eth_driver_register(&rte_bnx2x_pmd);
-
- return 0;
-}
-
-static int rte_bnx2xvf_pmd_init(const char *name __rte_unused, const char
*params __rte_unused)
-{
- PMD_INIT_FUNC_TRACE();
- rte_eth_driver_register(&rte_bnx2xvf_pmd);
-
- return 0;
-}
-
-static struct rte_driver rte_bnx2x_driver = {
- .type = PMD_PDEV,
- .init = rte_bnx2x_pmd_init,
-};
-
-static struct rte_driver rte_bnx2xvf_driver = {
- .type = PMD_PDEV,
- .init = rte_bnx2xvf_pmd_init,
-};
-
-PMD_REGISTER_DRIVER(rte_bnx2x_driver);
-PMD_REGISTER_DRIVER(rte_bnx2xvf_driver);
+RTE_EAL_PCI_REGISTER(bnx2xvf, rte_bnx2xvf_pmd.pci_drv);
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index bb134e5..72b1a7b 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -870,29 +870,11 @@ static struct eth_driver rte_cxgbe_pmd = {
.name = "rte_cxgbe_pmd",
.id_table = cxgb4_pci_tbl,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
+ .devinit = rte_eth_dev_pci_probe,
+ .devunin
[dpdk-dev] [PATCH v2 09/17] crypto: get rid of crypto driver register callback
Now that all pdev are pci drivers, we don't need to register crypto drivers
through a dedicated channel.
Signed-off-by: David Marchand
---
lib/librte_cryptodev/rte_cryptodev.c | 22 ---
lib/librte_cryptodev/rte_cryptodev_pmd.h | 30 --
lib/librte_cryptodev/rte_cryptodev_version.map | 1 -
3 files changed, 53 deletions(-)
diff --git a/lib/librte_cryptodev/rte_cryptodev.c
b/lib/librte_cryptodev/rte_cryptodev.c
index 19a9939..d9648a2 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -444,28 +444,6 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
return 0;
}
-int
-rte_cryptodev_pmd_driver_register(struct rte_cryptodev_driver *cryptodrv,
- enum pmd_type type)
-{
- /* Call crypto device initialization directly if device is virtual */
- if (type == PMD_VDEV)
- return rte_cryptodev_pci_probe((struct rte_pci_driver
*)cryptodrv,
- NULL);
-
- /*
-* Register PCI driver for physical device intialisation during
-* PCI probing
-*/
- cryptodrv->pci_drv.devinit = rte_cryptodev_pci_probe;
- cryptodrv->pci_drv.devuninit = rte_cryptodev_pci_remove;
-
- rte_eal_pci_register(&cryptodrv->pci_drv);
-
- return 0;
-}
-
-
uint16_t
rte_cryptodev_queue_pair_count(uint8_t dev_id)
{
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 3fb7c7c..99fd69e 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -491,36 +491,6 @@ rte_cryptodev_pmd_virtual_dev_init(const char *name,
size_t dev_private_size,
extern int
rte_cryptodev_pmd_release_device(struct rte_cryptodev *cryptodev);
-
-/**
- * Register a Crypto [Poll Mode] driver.
- *
- * Function invoked by the initialization function of a Crypto driver
- * to simultaneously register itself as Crypto Poll Mode Driver and to either:
- *
- * a - register itself as PCI driver if the crypto device is a physical
- * device, by invoking the rte_eal_pci_register() function to
- * register the *pci_drv* structure embedded in the *crypto_drv*
- * structure, after having stored the address of the
- * rte_cryptodev_init() function in the *devinit* field of the
- * *pci_drv* structure.
- *
- * During the PCI probing phase, the rte_cryptodev_init()
- * function is invoked for each PCI [device] matching the
- * embedded PCI identifiers provided by the driver.
- *
- * b, complete the initialization sequence if the device is a virtual
- * device by calling the rte_cryptodev_init() directly passing a
- * NULL parameter for the rte_pci_device structure.
- *
- * @param crypto_drv crypto_driver structure associated with the crypto
- * driver.
- * @param type pmd type
- */
-extern int
-rte_cryptodev_pmd_driver_register(struct rte_cryptodev_driver *crypto_drv,
- enum pmd_type type);
-
/**
* Executes all the user application registered callbacks for the specific
* device.
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map
b/lib/librte_cryptodev/rte_cryptodev_version.map
index 8d0edfb..e0a9620 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -14,7 +14,6 @@ DPDK_16.04 {
rte_cryptodev_info_get;
rte_cryptodev_pmd_allocate;
rte_cryptodev_pmd_callback_process;
- rte_cryptodev_pmd_driver_register;
rte_cryptodev_pmd_release_device;
rte_cryptodev_pmd_virtual_dev_init;
rte_cryptodev_sym_session_create;
--
1.9.1
[dpdk-dev] [PATCH v2 10/17] ethdev: get rid of eth driver register callback
Now that all pdev are pci drivers, we don't need to register ethdev drivers
through a dedicated channel.
Signed-off-by: David Marchand
---
lib/librte_ether/rte_ethdev.c | 22 --
lib/librte_ether/rte_ethdev.h | 12
lib/librte_ether/rte_ether_version.map | 1 -
3 files changed, 35 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 7b908a7..7ec8cdb 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -334,28 +334,6 @@ rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
return 0;
}
-/**
- * Register an Ethernet [Poll Mode] driver.
- *
- * Function invoked by the initialization function of an Ethernet driver
- * to simultaneously register itself as a PCI driver and as an Ethernet
- * Poll Mode Driver.
- * Invokes the rte_eal_pci_register() function to register the *pci_drv*
- * structure embedded in the *eth_drv* structure, after having stored the
- * address of the rte_eth_dev_init() function in the *devinit* field of
- * the *pci_drv* structure.
- * During the PCI probing phase, the rte_eth_dev_init() function is
- * invoked for each PCI [Ethernet device] matching the embedded PCI
- * identifiers provided by the driver.
- */
-void
-rte_eth_driver_register(struct eth_driver *eth_drv)
-{
- eth_drv->pci_drv.devinit = rte_eth_dev_pci_probe;
- eth_drv->pci_drv.devuninit = rte_eth_dev_pci_remove;
- rte_eal_pci_register(ð_drv->pci_drv);
-}
-
int
rte_eth_dev_is_valid_port(uint8_t port_id)
{
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 7a7a69e..016ce33 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1868,18 +1868,6 @@ struct eth_driver {
};
/**
- * @internal
- * A function invoked by the initialization function of an Ethernet driver
- * to simultaneously register itself as a PCI driver and as an Ethernet
- * Poll Mode Driver (PMD).
- *
- * @param eth_drv
- * The pointer to the *eth_driver* structure associated with
- * the Ethernet driver.
- */
-void rte_eth_driver_register(struct eth_driver *eth_drv);
-
-/**
* Convert a numerical speed in Mbps to a bitmap flag that can be used in
* the bitmap link_speeds of the struct rte_eth_conf
*
diff --git a/lib/librte_ether/rte_ether_version.map
b/lib/librte_ether/rte_ether_version.map
index 31017d4..d457b21 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -80,7 +80,6 @@ DPDK_2.2 {
rte_eth_dev_vlan_filter;
rte_eth_dev_wd_timeout_store;
rte_eth_dma_zone_reserve;
- rte_eth_driver_register;
rte_eth_led_off;
rte_eth_led_on;
rte_eth_link;
--
1.9.1
[dpdk-dev] [PATCH v2 11/17] eal/linux: move back interrupt thread init before setting affinity
Now that virtio pci driver is initialized in a constructor, iopl() stuff
happens early enough so that interrupt thread can be created right after
plugin loading.
This way, chelsio driver should be happy again [1].
[1] http://dpdk.org/ml/archives/dev/2015-November/028289.html
Signed-off-by: David Marchand
Tested-by: Rahul Lakkireddy
---
lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index f26f8d3..4b28197 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -825,6 +825,9 @@ rte_eal_init(int argc, char **argv)
if (eal_plugins_init() < 0)
rte_panic("Cannot init plugins\n");
+ if (rte_eal_intr_init() < 0)
+ rte_panic("Cannot init interrupt-handling thread\n");
+
eal_thread_init_master(rte_config.master_lcore);
ret = eal_thread_dump_affinity(cpuset, RTE_CPU_AFFINITY_STR_LEN);
@@ -836,9 +839,6 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_dev_init() < 0)
rte_panic("Cannot init pmd devices\n");
- if (rte_eal_intr_init() < 0)
- rte_panic("Cannot init interrupt-handling thread\n");
-
RTE_LCORE_FOREACH_SLAVE(i) {
/*
--
1.9.1
[dpdk-dev] [PATCH v2 12/17] pci: add a helper for device name
eal is a better place than crypto / ethdev for naming resources.
Add a helper in eal and make use of it in crypto / ethdev.
Signed-off-by: David Marchand
---
lib/librte_cryptodev/rte_cryptodev.c| 27 ---
lib/librte_eal/common/include/rte_pci.h | 25 +
lib/librte_ether/rte_ethdev.c | 24
3 files changed, 33 insertions(+), 43 deletions(-)
diff --git a/lib/librte_cryptodev/rte_cryptodev.c
b/lib/librte_cryptodev/rte_cryptodev.c
index d9648a2..6f4d1c4 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -276,23 +276,6 @@ rte_cryptodev_pmd_allocate(const char *name, int socket_id)
return cryptodev;
}
-static inline int
-rte_cryptodev_create_unique_device_name(char *name, size_t size,
- struct rte_pci_device *pci_dev)
-{
- int ret;
-
- if ((name == NULL) || (pci_dev == NULL))
- return -EINVAL;
-
- ret = snprintf(name, size, "%d:%d.%d",
- pci_dev->addr.bus, pci_dev->addr.devid,
- pci_dev->addr.function);
- if (ret < 0)
- return ret;
- return 0;
-}
-
int
rte_cryptodev_pmd_release_device(struct rte_cryptodev *cryptodev)
{
@@ -355,9 +338,8 @@ rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
if (cryptodrv == NULL)
return -ENODEV;
- /* Create unique Crypto device name using PCI address */
- rte_cryptodev_create_unique_device_name(cryptodev_name,
- sizeof(cryptodev_name), pci_dev);
+ rte_eal_pci_device_name(&pci_dev->addr, cryptodev_name,
+ sizeof(cryptodev_name));
cryptodev = rte_cryptodev_pmd_allocate(cryptodev_name, rte_socket_id());
if (cryptodev == NULL)
@@ -412,9 +394,8 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
if (pci_dev == NULL)
return -EINVAL;
- /* Create unique device name using PCI address */
- rte_cryptodev_create_unique_device_name(cryptodev_name,
- sizeof(cryptodev_name), pci_dev);
+ rte_eal_pci_device_name(&pci_dev->addr, cryptodev_name,
+ sizeof(cryptodev_name));
cryptodev = rte_cryptodev_pmd_get_named_dev(cryptodev_name);
if (cryptodev == NULL)
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index f99b33a..3bb1833 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -82,6 +82,7 @@ extern "C" {
#include
#include
+#include
#include
TAILQ_HEAD(pci_device_list, rte_pci_device); /**< PCI devices in D-linked Q. */
@@ -95,6 +96,7 @@ extern struct pci_device_list pci_device_list; /**< Global
list of PCI devices.
/** Formatting string for PCI device identifier: Ex: :00:01.0 */
#define PCI_PRI_FMT "%.4" PRIx16 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
+#define PCI_PRI_STR_SIZE sizeof(":XX:XX.X")
/** Short formatting string, without domain, for PCI device: Ex: 00:01.0 */
#define PCI_SHORT_PRI_FMT "%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
@@ -309,6 +311,29 @@ eal_parse_pci_DomBDF(const char *input, struct
rte_pci_addr *dev_addr)
}
#undef GET_PCIADDR_FIELD
+/**
+ * Utility function to write a pci device name, this device name can later be
+ * used to retrieve the corresponding rte_pci_addr using above functions.
+ *
+ * @param addr
+ * The PCI Bus-Device-Function address
+ * @param output
+ * The output buffer string
+ * @param size
+ * The output buffer size
+ * @return
+ * 0 on success, negative on error.
+ */
+static inline void
+rte_eal_pci_device_name(const struct rte_pci_addr *addr,
+ char *output, size_t size)
+{
+ RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
+ RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
+ addr->domain, addr->bus,
+ addr->devid, addr->function) >= 0);
+}
+
/* Compare two PCI device addresses. */
/**
* Utility function to compare two PCI device addresses.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 7ec8cdb..9d5827b 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -214,20 +214,6 @@ rte_eth_dev_allocate(const char *name, enum
rte_eth_dev_type type)
return eth_dev;
}
-static int
-rte_eth_dev_create_unique_device_name(char *name, size_t size,
- struct rte_pci_device *pci_dev)
-{
- int ret;
-
- ret = snprintf(name, size, "%d:%d.%d",
- pci_dev->addr.bus, pci_dev->addr.devid,
- pci_dev->addr.function);
- if (ret < 0)
- return ret;
- return 0;
-}
-
int
rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
{
@@ -251,9 +237,8 @@ rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
eth_drv = (struct eth_driver *)pci_drv;
-
[dpdk-dev] [PATCH v2 13/17] pci: add a helper to update a device
This helper updates a pci device object with latest information it can
find.
It will be used mainly for hotplug code.
Signed-off-by: David Marchand
---
lib/librte_eal/bsdapp/eal/eal_pci.c | 49 +++
lib/librte_eal/common/eal_private.h | 13 ++
lib/librte_eal/linuxapp/eal/eal_pci.c | 13 ++
3 files changed, 75 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index cd8e8d3..85e49f6 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -401,6 +401,55 @@ error:
return -1;
}
+int
+pci_update_device(const struct rte_pci_addr *addr)
+{
+ int fd;
+ struct pci_conf matches[2];
+ struct pci_match_conf match = {
+ .pc_sel = {
+ .pc_domain = addr->domain,
+ .pc_bus = addr->bus,
+ .pc_dev = addr->devid,
+ .pc_func = addr->function,
+ },
+ };
+ struct pci_conf_io conf_io = {
+ .pat_buf_len = 0,
+ .num_patterns = 1,
+ .patterns = &match,
+ .match_buf_len = sizeof(matches),
+ .matches = &matches[0],
+ };
+
+ fd = open("/dev/pci", O_RDONLY);
+ if (fd < 0) {
+ RTE_LOG(ERR, EAL, "%s(): error opening /dev/pci\n", __func__);
+ goto error;
+ }
+
+ if (ioctl(fd, PCIOCGETCONF, &conf_io) < 0) {
+ RTE_LOG(ERR, EAL, "%s(): error with ioctl on /dev/pci: %s\n",
+ __func__, strerror(errno));
+ goto error;
+ }
+
+ if (conf_io.num_matches != 1)
+ goto error;
+
+ if (pci_scan_one(fd, &matches[0]) < 0)
+ goto error;
+
+ close(fd);
+
+ return 0;
+
+error:
+ if (fd >= 0)
+ close(fd);
+ return -1;
+}
+
/* Read PCI config space. */
int rte_eal_pci_read_config(const struct rte_pci_device *dev,
void *buf, size_t len, off_t offset)
diff --git a/lib/librte_eal/common/eal_private.h
b/lib/librte_eal/common/eal_private.h
index 855fd25..81816a6 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -155,6 +155,19 @@ struct rte_pci_driver;
struct rte_pci_device;
/**
+ * Update a pci device object by asking the kernel for the latest information.
+ *
+ * This function is private to EAL.
+ *
+ * @param addr
+ * The PCI Bus-Device-Function address to look for
+ * @return
+ * - 0 on success.
+ * - negative on error.
+ */
+int pci_update_device(const struct rte_pci_addr *addr);
+
+/**
* Unbind kernel driver for this device
*
* This function is private to EAL.
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 3fc82b0..61ac21f 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -393,6 +393,19 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t
bus,
return 0;
}
+int
+pci_update_device(const struct rte_pci_addr *addr)
+{
+ char filename[PATH_MAX];
+
+ snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
+SYSFS_PCI_DEVICES, addr->domain, addr->bus, addr->devid,
+addr->function);
+
+ return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
+ addr->function);
+}
+
/*
* split up a pci address into its constituent parts.
*/
--
1.9.1
[dpdk-dev] [PATCH v2 14/17] ethdev: do not scan all pci devices on attach
No need to scan all devices, we only need to update the device being
attached.
Signed-off-by: David Marchand
---
lib/librte_eal/common/eal_common_pci.c | 11 ---
lib/librte_ether/rte_ethdev.c | 3 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 80d8ec6..d63b47b 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -325,6 +325,11 @@ rte_eal_pci_probe_one(const struct rte_pci_addr *addr)
if (addr == NULL)
return -1;
+ /* update current pci device in global list, kernel bindings might have
+* changed since last time we looked at it */
+ if (pci_update_device(addr) < 0)
+ goto err_return;
+
TAILQ_FOREACH(dev, &pci_device_list, next) {
if (rte_eal_compare_pci_addr(&dev->addr, addr))
continue;
@@ -337,9 +342,9 @@ rte_eal_pci_probe_one(const struct rte_pci_addr *addr)
return -1;
err_return:
- RTE_LOG(WARNING, EAL, "Requested device " PCI_PRI_FMT
- " cannot be used\n", dev->addr.domain, dev->addr.bus,
- dev->addr.devid, dev->addr.function);
+ RTE_LOG(WARNING, EAL,
+ "Requested device " PCI_PRI_FMT " cannot be used\n",
+ addr->domain, addr->bus, addr->devid, addr->function);
return -1;
}
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 9d5827b..6cd6455 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -468,9 +468,6 @@ rte_eth_dev_is_detachable(uint8_t port_id)
static int
rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t *port_id)
{
- /* re-construct pci_device_list */
- if (rte_eal_pci_scan())
- goto err;
/* Invoke probe func of the driver can handle the new device. */
if (rte_eal_pci_probe_one(addr))
goto err;
--
1.9.1
[dpdk-dev] [PATCH v2 15/17] eal: add hotplug operations for pci and vdev
hotplug which deals with resources should come from the layer that already
handles them, i.e. eal.
For both attach and detach operations, 'name' is used to select the bus
that will handle the request.
Signed-off-by: David Marchand
---
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 8 +
lib/librte_eal/common/eal_common_dev.c | 39 +
lib/librte_eal/common/include/rte_dev.h | 25
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 8 +
4 files changed, 80 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 58c2951..4d075df 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -151,3 +151,11 @@ DPDK_16.04 {
rte_eal_primary_proc_alive;
} DPDK_2.2;
+
+DPDK_16.07 {
+ global:
+
+ rte_eal_dev_attach;
+ rte_eal_dev_detach;
+
+} DPDK_16.04;
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common/eal_common_dev.c
index a8a4146..59ed3a0 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -150,3 +150,42 @@ rte_eal_vdev_uninit(const char *name)
RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
return -EINVAL;
}
+
+int rte_eal_dev_attach(const char *name, const char *devargs)
+{
+ struct rte_pci_addr addr;
+ int ret = -1;
+
+ if (eal_parse_pci_DomBDF(name, &addr) == 0) {
+ if (rte_eal_pci_probe_one(&addr) < 0)
+ goto err;
+
+ } else {
+ if (rte_eal_vdev_init(name, devargs))
+ goto err;
+ }
+
+ return 0;
+
+err:
+ RTE_LOG(ERR, EAL, "Driver, cannot attach the device\n");
+ return ret;
+}
+
+int rte_eal_dev_detach(const char *name)
+{
+ struct rte_pci_addr addr;
+
+ if (eal_parse_pci_DomBDF(name, &addr) == 0) {
+ if (rte_eal_pci_detach(&addr) < 0)
+ goto err;
+ } else {
+ if (rte_eal_vdev_uninit(name))
+ goto err;
+ }
+ return 0;
+
+err:
+ RTE_LOG(ERR, EAL, "Driver, cannot detach the device\n");
+ return -1;
+}
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index 85e48f2..b1c0520 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -178,6 +178,31 @@ int rte_eal_vdev_init(const char *name, const char *args);
*/
int rte_eal_vdev_uninit(const char *name);
+/**
+ * Attach a resource to a registered driver.
+ *
+ * @param name
+ * The resource name, that refers to a pci resource or some private
+ * way of designating a resource for vdev drivers. Based on this
+ * resource name, eal will identify a driver capable of handling
+ * this resource and pass this resource to the driver probing
+ * function.
+ * @param devargs
+ * Device arguments to be passed to the driver.
+ * @return
+ * 0 on success, negative on error.
+ */
+int rte_eal_dev_attach(const char *name, const char *devargs);
+
+/**
+ * Detach a resource from its driver.
+ *
+ * @param name
+ * Same description as for rte_eal_dev_attach().
+ * Here, eal will call the driver detaching function.
+ */
+int rte_eal_dev_detach(const char *name);
+
#define PMD_REGISTER_DRIVER(d)\
RTE_INIT(devinitfn_ ##d);\
static void devinitfn_ ##d(void)\
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 12503ef..0404a52 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -154,3 +154,11 @@ DPDK_16.04 {
rte_eal_primary_proc_alive;
} DPDK_2.2;
+
+DPDK_16.07 {
+ global:
+
+ rte_eal_dev_attach;
+ rte_eal_dev_detach;
+
+} DPDK_16.04;
--
1.9.1
[dpdk-dev] [PATCH v2 16/17] ethdev: convert to eal hotplug
Remove bus logic from ethdev hotplug by using eal for this.
Current api is preserved:
- the last port that has been created is tracked to return it to the
application when attaching,
- the internal device name is reused when detaching.
We can not get rid of ethdev hotplug yet since we still need some mechanism
to inform applications of port creation/removal to substitute for ethdev
hotplug api.
dev_type field in struct rte_eth_dev and rte_eth_dev_allocate are kept as
is, but this information is not needed anymore and is removed in the following
commit.
Signed-off-by: David Marchand
---
lib/librte_ether/rte_ethdev.c | 252 ++
1 file changed, 33 insertions(+), 219 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 6cd6455..1794025 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -72,6 +72,7 @@
static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
static struct rte_eth_dev_data *rte_eth_dev_data;
+static uint8_t eth_dev_last_created_port;
static uint8_t nb_ports;
/* spinlock for eth device callbacks */
@@ -210,6 +211,7 @@ rte_eth_dev_allocate(const char *name, enum
rte_eth_dev_type type)
eth_dev->data->port_id = port_id;
eth_dev->attached = DEV_ATTACHED;
eth_dev->dev_type = type;
+ eth_dev_last_created_port = port_id;
nb_ports++;
return eth_dev;
}
@@ -342,100 +344,6 @@ rte_eth_dev_count(void)
return nb_ports;
}
-static enum rte_eth_dev_type
-rte_eth_dev_get_device_type(uint8_t port_id)
-{
- if (!rte_eth_dev_is_valid_port(port_id))
- return RTE_ETH_DEV_UNKNOWN;
- return rte_eth_devices[port_id].dev_type;
-}
-
-static int
-rte_eth_dev_get_addr_by_port(uint8_t port_id, struct rte_pci_addr *addr)
-{
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
-
- if (addr == NULL) {
- RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
- return -EINVAL;
- }
-
- *addr = rte_eth_devices[port_id].pci_dev->addr;
- return 0;
-}
-
-static int
-rte_eth_dev_get_name_by_port(uint8_t port_id, char *name)
-{
- char *tmp;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
-
- if (name == NULL) {
- RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
- return -EINVAL;
- }
-
- /* shouldn't check 'rte_eth_devices[i].data',
-* because it might be overwritten by VDEV PMD */
- tmp = rte_eth_dev_data[port_id].name;
- strcpy(name, tmp);
- return 0;
-}
-
-static int
-rte_eth_dev_get_port_by_name(const char *name, uint8_t *port_id)
-{
- int i;
-
- if (name == NULL) {
- RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
- return -EINVAL;
- }
-
- *port_id = RTE_MAX_ETHPORTS;
-
- for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
-
- if (!strncmp(name,
- rte_eth_dev_data[i].name, strlen(name))) {
-
- *port_id = i;
-
- return 0;
- }
- }
- return -ENODEV;
-}
-
-static int
-rte_eth_dev_get_port_by_addr(const struct rte_pci_addr *addr, uint8_t *port_id)
-{
- int i;
- struct rte_pci_device *pci_dev = NULL;
-
- if (addr == NULL) {
- RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
- return -EINVAL;
- }
-
- *port_id = RTE_MAX_ETHPORTS;
-
- for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
-
- pci_dev = rte_eth_devices[i].pci_dev;
-
- if (pci_dev &&
- !rte_eal_compare_pci_addr(&pci_dev->addr, addr)) {
-
- *port_id = i;
-
- return 0;
- }
- }
- return -ENODEV;
-}
-
static int
rte_eth_dev_is_detachable(uint8_t port_id)
{
@@ -464,124 +372,45 @@ rte_eth_dev_is_detachable(uint8_t port_id)
return 1;
}
-/* attach the new physical device, then store port_id of the device */
-static int
-rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t *port_id)
-{
- /* Invoke probe func of the driver can handle the new device. */
- if (rte_eal_pci_probe_one(addr))
- goto err;
-
- if (rte_eth_dev_get_port_by_addr(addr, port_id))
- goto err;
-
- return 0;
-err:
- return -1;
-}
-
-/* detach the new physical device, then store pci_addr of the device */
-static int
-rte_eth_dev_detach_pdev(uint8_t port_id, struct rte_pci_addr *addr)
-{
- struct rte_pci_addr freed_addr;
- struct rte_pci_addr vp;
-
- /* get pci address by port id */
- if (rte_eth_dev_get_addr_by_port(port_id, &freed_addr))
- goto err;
-
- /* Zeroed pci addr means the port comes from virtual device */
- vp.domain = vp.bus = vp.devid = vp.functi
[dpdk-dev] [PATCH v2 17/17] ethdev: get rid of device type
Now that hotplug has been moved to eal, there is no reason to keep the device
type in this layer.
Signed-off-by: David Marchand
---
app/test/virtual_pmd.c| 2 +-
drivers/net/af_packet/rte_eth_af_packet.c | 2 +-
drivers/net/bonding/rte_eth_bond_api.c| 2 +-
drivers/net/cxgbe/cxgbe_main.c| 2 +-
drivers/net/mlx4/mlx4.c | 2 +-
drivers/net/mlx5/mlx5.c | 2 +-
drivers/net/mpipe/mpipe_tilegx.c | 2 +-
drivers/net/null/rte_eth_null.c | 2 +-
drivers/net/pcap/rte_eth_pcap.c | 2 +-
drivers/net/ring/rte_eth_ring.c | 2 +-
drivers/net/vhost/rte_eth_vhost.c | 2 +-
drivers/net/xenvirt/rte_eth_xenvirt.c | 2 +-
examples/ip_pipeline/init.c | 22 --
lib/librte_ether/rte_ethdev.c | 5 ++---
lib/librte_ether/rte_ethdev.h | 15 +--
15 files changed, 15 insertions(+), 51 deletions(-)
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index b4bd2f2..8a1f0d0 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -581,7 +581,7 @@ virtual_ethdev_create(const char *name, struct ether_addr
*mac_addr,
goto err;
/* reserve an ethdev entry */
- eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+ eth_dev = rte_eth_dev_allocate(name);
if (eth_dev == NULL)
goto err;
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index f17bd7e..36ac102 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -648,7 +648,7 @@ rte_pmd_init_internals(const char *name,
}
/* reserve an ethdev entry */
- *eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_VIRTUAL);
+ *eth_dev = rte_eth_dev_allocate(name);
if (*eth_dev == NULL)
goto error;
diff --git a/drivers/net/bonding/rte_eth_bond_api.c
b/drivers/net/bonding/rte_eth_bond_api.c
index e9247b5..c72807c 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -193,7 +193,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t
socket_id)
}
/* reserve an ethdev entry */
- eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_VIRTUAL);
+ eth_dev = rte_eth_dev_allocate(name);
if (eth_dev == NULL) {
RTE_BOND_LOG(ERR, "Unable to allocate rte_eth_dev");
goto err;
diff --git a/drivers/net/cxgbe/cxgbe_main.c b/drivers/net/cxgbe/cxgbe_main.c
index ceaf5ab..922155b 100644
--- a/drivers/net/cxgbe/cxgbe_main.c
+++ b/drivers/net/cxgbe/cxgbe_main.c
@@ -1150,7 +1150,7 @@ int cxgbe_probe(struct adapter *adapter)
*/
/* reserve an ethdev entry */
- pi->eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+ pi->eth_dev = rte_eth_dev_allocate(name);
if (!pi->eth_dev)
goto out_free;
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 8e4b0cc..0c76e72 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5667,7 +5667,7 @@ mlx4_pci_devinit(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
snprintf(name, sizeof(name), "%s port %u",
ibv_get_device_name(ibv_dev), port);
- eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+ eth_dev = rte_eth_dev_allocate(name);
}
if (eth_dev == NULL) {
ERROR("can not allocate rte ethdev");
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 1989a37..f6399fc 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -519,7 +519,7 @@ mlx5_pci_devinit(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
snprintf(name, sizeof(name), "%s port %u",
ibv_get_device_name(ibv_dev), port);
- eth_dev = rte_eth_dev_allocate(name, RTE_ETH_DEV_PCI);
+ eth_dev = rte_eth_dev_allocate(name);
}
if (eth_dev == NULL) {
ERROR("can not allocate rte ethdev");
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index adcbc19..4e29931 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -1587,7 +1587,7 @@ rte_pmd_mpipe_devinit(const char *ifname,
return -ENODEV;
}
- eth_dev = rte_eth_dev_allocate(ifname, RTE_ETH_DEV_VIRTUAL);
+ eth_dev = rte_eth_dev_allocate(ifname);
if (!eth_dev) {
RTE_LOG(ERR, PMD, "%s: Failed to allocate device.\n", ifname);
rte_free(priv);
diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
On Wed, Apr 20, 2016 at 01:44:00PM +0200, David Marchand wrote: > Following discussions with Jan [1] and some cleanup I started on pci code, > here is a patchset that reworks pdev drivers registration and hotplug api. > > The structures changes mentioned in [1] are still to be done, but at least, > I think we are one step closer to it. > > Before this patchset, rte_driver .init semantics differed whether it > concerned a pdev or a vdev driver: > - for vdev, it actually meant that a devargs is given to the driver so > that it creates ethdev / crypto objects, so it was a probing action > - for pdev, it only registered the driver triggering no ethdev / crypto > objects > > From my pov, eal hotplug api introduced in this patchset still needs more > work so that it does not need to know about devargs. So a new devargs api > is needed. > > Changes since v1: > - rebased on HEAD, new drivers should be okay > - patches have been split into smaller pieces > - RTE_INIT macro has been added, but in the end, I am not sure it is useful > - device type has been removed from ethdev, as it was used only by hotplug > - getting rid of pmd type in eal patch (patch 5 of initial series) has been > dropped for now, we can do this once vdev drivers have been converted > > [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html > > Regards, > -- > David Marchand > Nice, David. Looks to be some good improvements in there! /Bruce
[dpdk-dev] Couple of PMD questions
On Wed, Apr 20, 2016 at 4:10 AM, Bruce Richardson < bruce.richardson at intel.com> wrote: > On Tue, Apr 19, 2016 at 03:16:37PM -0500, Jay Rolette wrote: > > In ixgbe_dev_rx_init(), there is this bit of code: > > > > /* > >* Configure the RX buffer size in the BSIZEPACKET field of > >* the SRRCTL register of the queue. > >* The value is in 1 KB resolution. Valid values can be from > >* 1 KB to 16 KB. > >*/ > > buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mb_pool) - > > RTE_PKTMBUF_HEADROOM); > > srrctl |= ((buf_size >> IXGBE_SRRCTL_BSIZEPKT_SHIFT) & > > IXGBE_SRRCTL_BSIZEPKT_MASK); > > > > IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(rxq->reg_idx), srrctl); > > > > buf_size = (uint16_t) ((srrctl & IXGBE_SRRCTL_BSIZEPKT_MASK) << > > IXGBE_SRRCTL_BSIZEPKT_SHIFT); > > > > /* It adds dual VLAN length for supporting dual VLAN */ > > if (dev->data->dev_conf.rxmode.max_rx_pkt_len + > > 2 * IXGBE_VLAN_TAG_SIZE > buf_size) > > dev->data->scattered_rx = 1; > > > > > > Couple of questions I have about it: > > > > 1) If the caller configured the MBUF memory pool data room size to be > > something other than a multiple of 1K (+ RTE_PKTMBUF_HEADROOM), then the > > driver ends up silently programming the NIC to use a smaller max RX size > > than the caller specified. > > > > Should the driver error out in that case instead of only "sort of" > working? > > If not, it seems like it should be logging an error message. > > Well, it does log at the end of the whole rx init process what RX function > is > being used, so there is that. > However, looking at it now, given that there is an explicit setting in the > config > to request scattered mode, I think you may be right and that we should > error out > here if scattered mode is needed and not set. It could help prevent > unexpected > problems with these drivers. > +1. A hard fail at init if I've misconfigured things is much preferred to something that mostly works for typical test cases and only fails on corner/limit testing. > > 2) Second question is about the "/* It adds dual VLAN length for > supporting > > dual VLAN */" bit... > > > > As I understand it, dev_conf.rxmode.max_rx_pkt_len is supposed to be set > to > > the max frame size you support (although it says it's only used if jumbo > > frame is enabled). That same value is generally used when calculating the > > size that mbuf elements should be created at. > > > > The description for the data_room_size parameter of > > rte_pktmbuf_pool_create(): > > > > "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM." > > > > > > If I support a max frame size of 9216 bytes (exactly a 1K multiple to > make > > the NIC happy), then max_rx_pkt_len is going to be 9216 and > data_room_size > > will be 9216 + RTE_PKTMBUF_HEADROOM. > > > > ixgbe_dev_rx_init() will calculate normalize that back to 9216, which > will > > fail the dual VLAN length check. The really nasty part about that is it > has > > a side-effect of enabling scattered RX regardless of the fact that I > didn't > > enable scattered RX in dev_conf.rxmode. > > > > The code in the e1000 PMD is similar, so nothing unique to ixgbe. > > > > Is that check correct? It seems wrong to be adding space for q-in-q on > top > > of your specified max frame size... > > The issue here is what the correct behaviour needs to be. If we have the > user > specify the maximum frame size including all vlan tags, then we hit the > problem > where we have to subtract the VLAN tag sizes when writing the value to the > NIC. > In that case, we will hit a problem where we get a e.g. 9210 byte frame - > to > reuse your example - without any VLAN tags, which will be rejected by the > hardware as being oversized. If we don't do the subtraction, and we get the > same 9210 byte packet with 2 VLAN tags on it, the hardware will accept it > and > then split it across multiple descriptors because the actual DMA size is > 9218 bytes. > As an app developer, I didn't realize the max frame size didn't include VLAN tags. I expected max frame size to be the size of the ethernet frame on the wire, which I would expect to include space used by any VLAN or MPLS tags. Is there anything in the docs or example apps about that? I did some digging as I was debugging this and didn't notice it, but entirely possible I just missed it. > I'm not sure there is a works-in-all-cases solution here. > Andriy's suggestion seems like it points in the right direction. >From an app developer point of view, I'd expect to have a single max frame size value to track and the APIs should take care of any adjustments required internally. Maybe have rte_pktmbuf_pool_create() add the additional bytes when it calls rte_mempool_create() under the covers? Then it's nice and clean for the API without unexpected side-effects. Jay > /Bruc
[dpdk-dev] [PATCH v2 05/17] eal: introduce init macros
Hello,
just an idea...
On Wed, 20 Apr 2016 13:44:05 +0200
David Marchand wrote:
> Introduce a RTE_INIT macro used to mark an init function as a constructor.
> Current eal macros have been converted to use this (no functional impact).
> RTE_EAL_PCI_REGISTER is added as a helper for pci drivers.
>
> Suggested-by: Jan Viktorin
> Signed-off-by: David Marchand
> ---
[...]
> diff --git a/lib/librte_eal/common/include/rte_pci.h
> b/lib/librte_eal/common/include/rte_pci.h
> index e692094..f99b33a 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -471,6 +471,13 @@ void rte_eal_pci_dump(FILE *f);
> */
> void rte_eal_pci_register(struct rte_pci_driver *driver);
>
> +#define RTE_EAL_PCI_REGISTER(name, d) \
What about a simple version with just a single argument?
#define RTE_EAL_PCI_REGISTER(name)
RTE_INIT(pciinitfn_ ##name); \
static void pciinitfn_ ##name(void) \
{ \
rte_eal_pci_register(&(name).pci_drv); \
}
Then the name pci_drv would be mandatory... But anyway, the 'name' and 'd'
are usually duplicates.
Regards
Jan
> +RTE_INIT(pciinitfn_ ##name); \
> +static void pciinitfn_ ##name(void) \
> +{ \
> + rte_eal_pci_register(&d); \
> +}
> +
> /**
> * Unregister a PCI driver.
> *
> diff --git a/lib/librte_eal/common/include/rte_tailq.h
> b/lib/librte_eal/common/include/rte_tailq.h
> index 4a686e6..71ed3bb 100644
> --- a/lib/librte_eal/common/include/rte_tailq.h
> +++ b/lib/librte_eal/common/include/rte_tailq.h
> @@ -148,8 +148,8 @@ struct rte_tailq_head *rte_eal_tailq_lookup(const char
> *name);
> int rte_eal_tailq_register(struct rte_tailq_elem *t);
>
> #define EAL_REGISTER_TAILQ(t) \
> -void tailqinitfn_ ##t(void); \
> -void __attribute__((constructor, used)) tailqinitfn_ ##t(void) \
> +RTE_INIT(tailqinitfn_ ##t); \
> +static void tailqinitfn_ ##t(void) \
> { \
> if (rte_eal_tailq_register(&t) < 0) \
> rte_panic("Cannot initialize tailq: %s\n", t.name); \
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
On Wed, 20 Apr 2016 13:05:24 +0100 Bruce Richardson wrote: > On Wed, Apr 20, 2016 at 01:44:00PM +0200, David Marchand wrote: > > Following discussions with Jan [1] and some cleanup I started on pci code, > > here is a patchset that reworks pdev drivers registration and hotplug api. > > > > The structures changes mentioned in [1] are still to be done, but at least, > > I think we are one step closer to it. > > > > Before this patchset, rte_driver .init semantics differed whether it > > concerned a pdev or a vdev driver: > > - for vdev, it actually meant that a devargs is given to the driver so > > that it creates ethdev / crypto objects, so it was a probing action > > - for pdev, it only registered the driver triggering no ethdev / crypto > > objects > > > > From my pov, eal hotplug api introduced in this patchset still needs more > > work so that it does not need to know about devargs. So a new devargs api > > is needed. > > > > Changes since v1: > > - rebased on HEAD, new drivers should be okay > > - patches have been split into smaller pieces > > - RTE_INIT macro has been added, but in the end, I am not sure it is useful > > - device type has been removed from ethdev, as it was used only by hotplug > > - getting rid of pmd type in eal patch (patch 5 of initial series) has been > > dropped for now, we can do this once vdev drivers have been converted > > > > [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html > > > > Regards, > > -- > > David Marchand > > > Nice, David. Looks to be some good improvements in there! > > /Bruce Looks good for me but I've failed to apply the series on top of commit 7d619406f31ddf115714b32778c33f6dc0ead470 Author: Thomas Monjalon Date: Thu Apr 14 20:49:49 2016 +0200 pci: remove deprecated specific config Jan
[dpdk-dev] [PATCH v3 00/13] kill global pci device id list
This patchset moves all pci device ids from eal to the pmds that need them. Global pci device id list is then removed. A new tool (name to be discussed) has been added to retrieve some information from the dpdk elf objects. I can't work on this subject at the moment, so please feel free to make these patches yours if you have better ideas / ways to achieve the same result. Changes since v2: - rebased on HEAD - ena driver has been aligned - this patchset now depends on [1] as it avoids touching all drivers this way - not storing the pci ids in a dedicated section anymore, pci drivers are exported and parsed by a quickly written (and naive) tool Changes since v1: - indent fixes in i40e, fm10k, virtio, vmxnet3, enic, bnx2c. - rebased on head (ixgbe update) - removed doc update (will be sent separately) [1]: http://dpdk.org/ml/archives/dev/2016-April/037686.html -- David Marchand David Marchand (13): e1000: move pci device ids to driver ixgbe: move pci device ids to driver i40e: move pci device ids to driver fm10k: move pci device ids to driver virtio: move pci device ids to driver vmxnet3: move pci device ids to driver enic: move pci device ids to driver bnx2x: move pci device ids to driver ena: remove unneeded pci macro pci: no need for global device ids list drivers: constify pci id tables drivers: export pci drivers app: introduce dpdk-obj-info tool app/Makefile| 1 + app/dpdk-obj-info/Makefile | 45 ++ app/dpdk-obj-info/dpdk-obj-info.c | 188 +++ app/test-pmd/Makefile | 2 + app/test-pmd/cmdline.c | 2 +- app/test/Makefile | 4 + app/test/test_pci.c | 5 +- doc/api/doxy-api-index.md | 1 - drivers/crypto/qat/rte_qat_cryptodev.c | 2 +- drivers/net/bnx2x/bnx2x.c | 3 +- drivers/net/bnx2x/bnx2x_ethdev.c| 25 +- drivers/net/cxgbe/cxgbe_ethdev.c| 2 +- drivers/net/e1000/em_ethdev.c | 2 +- drivers/net/e1000/em_pci_dev_ids.h | 208 +++ drivers/net/e1000/igb_ethdev.c | 4 +- drivers/net/e1000/igb_pci_dev_ids.h | 165 ++ drivers/net/ena/ena_ethdev.c| 10 +- drivers/net/enic/enic_ethdev.c | 13 +- drivers/net/fm10k/fm10k_ethdev.c| 7 +- drivers/net/i40e/i40e_ethdev.c | 21 +- drivers/net/i40e/i40e_ethdev_vf.c | 9 +- drivers/net/ixgbe/ixgbe_ethdev.c| 4 +- drivers/net/ixgbe/ixgbe_pci_dev_ids.h | 213 +++ drivers/net/mlx4/mlx4.c | 1 + drivers/net/mlx5/mlx5.c | 1 + drivers/net/nfp/nfp_net.c | 2 +- drivers/net/virtio/virtio_ethdev.c | 8 +- drivers/net/vmxnet3/vmxnet3_ethdev.c| 9 +- lib/librte_eal/common/Makefile | 2 +- lib/librte_eal/common/include/rte_pci.h | 7 + lib/librte_eal/common/include/rte_pci_dev_ids.h | 704 lib/librte_eal/linuxapp/kni/Makefile| 2 + lib/librte_eal/linuxapp/kni/kni_misc.c | 8 +- 33 files changed, 918 insertions(+), 762 deletions(-) create mode 100644 app/dpdk-obj-info/Makefile create mode 100644 app/dpdk-obj-info/dpdk-obj-info.c create mode 100644 drivers/net/e1000/em_pci_dev_ids.h create mode 100644 drivers/net/e1000/igb_pci_dev_ids.h create mode 100644 drivers/net/ixgbe/ixgbe_pci_dev_ids.h delete mode 100644 lib/librte_eal/common/include/rte_pci_dev_ids.h -- 1.9.1
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
test application and kni still want to know e1000 pci devices.
So let's create headers in the driver that will be used by them.
I wanted to reuse base/ headers, but because of some headaches trying to resolve
macros redefinition collisions in kni (with ixgbe next commit), I left it as is.
Signed-off-by: David Marchand
---
app/test/Makefile | 3 +
app/test/test_pci.c | 3 +-
drivers/net/e1000/em_ethdev.c | 2 +-
drivers/net/e1000/em_pci_dev_ids.h | 208 +++
drivers/net/e1000/igb_ethdev.c | 4 +-
drivers/net/e1000/igb_pci_dev_ids.h | 165 +++
lib/librte_eal/common/include/rte_pci_dev_ids.h | 254
lib/librte_eal/linuxapp/kni/Makefile| 1 +
lib/librte_eal/linuxapp/kni/kni_misc.c | 4 +-
9 files changed, 384 insertions(+), 260 deletions(-)
create mode 100644 drivers/net/e1000/em_pci_dev_ids.h
create mode 100644 drivers/net/e1000/igb_pci_dev_ids.h
diff --git a/app/test/Makefile b/app/test/Makefile
index a4907d5..8a1f54c 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -171,6 +171,9 @@ CFLAGS_test_memcpy_perf.o += -fno-var-tracking-assignments
endif
endif
+# pci tests want to know some pci devices ids
+CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/e1000
+
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 0ed357e..7215936 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -77,8 +77,9 @@ struct rte_pci_id my_driver_id2[] = {
/* IGB & EM NICS */
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
+#include
#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include
+#include
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 1f80c05..203a9e5 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -139,7 +139,7 @@ static enum e1000_fc_mode em_fc_setting = e1000_fc_full;
static const struct rte_pci_id pci_id_em_map[] = {
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+#include "em_pci_dev_ids.h"
{0},
};
diff --git a/drivers/net/e1000/em_pci_dev_ids.h
b/drivers/net/e1000/em_pci_dev_ids.h
new file mode 100644
index 000..736a68e
--- /dev/null
+++ b/drivers/net/e1000/em_pci_dev_ids.h
@@ -0,0 +1,208 @@
+/*-
+ * This file is provided under a dual BSD/GPLv2 license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.GPL.
+ *
+ * Contact Information:
+ * Intel Corporation
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
[dpdk-dev] [PATCH v3 02/13] ixgbe: move pci device ids to driver
test application and kni still want to know ixgbe pci devices.
So let's create a header in the driver that will be used by them.
Same comment as for e1000 driver, we can't reuse base/ headers at the moment
because of macros redefinitions nightmare.
Signed-off-by: David Marchand
---
app/test-pmd/Makefile | 2 +
app/test-pmd/cmdline.c | 2 +-
app/test/Makefile | 1 +
app/test/test_pci.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c| 4 +-
drivers/net/ixgbe/ixgbe_pci_dev_ids.h | 213
lib/librte_eal/common/include/rte_pci_dev_ids.h | 154 -
lib/librte_eal/linuxapp/kni/Makefile| 1 +
lib/librte_eal/linuxapp/kni/kni_misc.c | 4 +-
9 files changed, 223 insertions(+), 160 deletions(-)
create mode 100644 drivers/net/ixgbe/ixgbe_pci_dev_ids.h
diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index 72426f3..a8899b8 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -64,6 +64,8 @@ ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
CFLAGS_mempool_anon.o := -D_GNU_SOURCE
endif
CFLAGS_cmdline.o := -D_GNU_SOURCE
+# for bypass pci device ids
+CFLAGS_cmdline.o += -I$(RTE_SDK)/drivers/net/ixgbe
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index c5b9479..45cbcff 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -10586,7 +10586,7 @@ cmd_reconfig_device_queue(portid_t id, uint8_t dev,
uint8_t queue)
}
#ifdef RTE_NIC_BYPASS
-#include
+#include
uint8_t
bypass_is_supported(portid_t port_id)
{
diff --git a/app/test/Makefile b/app/test/Makefile
index 8a1f54c..051eb8c 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -173,6 +173,7 @@ endif
# pci tests want to know some pci devices ids
CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/e1000
+CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/ixgbe
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 7215936..cdb79ab 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -68,7 +68,7 @@ static int my_driver_init(struct rte_pci_driver *dr,
struct rte_pci_id my_driver_id[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBE(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include
+#include
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 5103c7c..098918a 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -421,7 +421,7 @@ static int ixgbe_dev_udp_tunnel_port_del(struct rte_eth_dev
*dev,
static const struct rte_pci_id pci_id_ixgbe_map[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBE(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+#include "ixgbe_pci_dev_ids.h"
{ .vendor_id = 0, /* sentinel */ },
};
@@ -433,7 +433,7 @@ static const struct rte_pci_id pci_id_ixgbe_map[] = {
static const struct rte_pci_id pci_id_ixgbevf_map[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+#include "ixgbe_pci_dev_ids.h"
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/ixgbe/ixgbe_pci_dev_ids.h
b/drivers/net/ixgbe/ixgbe_pci_dev_ids.h
new file mode 100644
index 000..467a281
--- /dev/null
+++ b/drivers/net/ixgbe/ixgbe_pci_dev_ids.h
@@ -0,0 +1,213 @@
+/*-
+ * This file is provided under a dual BSD/GPLv2 license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.GPL.
+ *
+ * Contact Information:
+ * Intel Corporation
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaime
[dpdk-dev] [PATCH v3 03/13] i40e: move pci device ids to driver
Since the base driver already defines all pci device ids, no need to
redefine them, let's just drop the previous RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/i40e/i40e_ethdev.c | 21 ++--
drivers/net/i40e/i40e_ethdev_vf.c | 9 ++--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 64 -
3 files changed, 24 insertions(+), 70 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 4e87399..b43acf1 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -448,9 +448,24 @@ static void i40e_set_default_mac_addr(struct rte_eth_dev
*dev,
struct ether_addr *mac_addr);
static const struct rte_pci_id pci_id_i40e_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_XL710) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QEMU) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops i40e_eth_dev_ops = {
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 1e41b3a..967324c 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1089,9 +1089,12 @@ i40evf_get_link_status(struct rte_eth_dev *dev, struct
rte_eth_link *link)
}
static const struct rte_pci_id pci_id_i40evf_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF_HV) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF_HV) },
+ { .vendor_id = 0, /* sentinel */ },
};
static inline int
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index ac2a6d6..f1f3e13 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -68,8 +68,6 @@
* driver which is a para virtualization driver running in guest virtual
machine.
* The inclusion of these in an array built using this file depends on the
* definition of
- * RTE_PCI_DEV_ID_DECL_I40E
- * RTE_PCI_DEV_ID_DECL_I40EVF
* RTE_PCI_DEV_ID_DECL_VIRTIO
* at the time when this file is included.
*
@@ -91,14 +89,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_I40E
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_I40EVF
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)
#endif
@@ -152,44 +142,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/*** Physical I40E devices from i40e_type.h */
-
-#define I40E_DEV_ID_SFP_XL710 0x1572
-#define I40E_DEV_ID_QEMU0x1574
-#define I40E_DEV_ID_KX_B0x1580
-#define I40E_DEV_ID_KX_C0x1581
-#define I40E_DEV_ID_QSFP_A 0x1583
-#define I40E_DEV_ID_QSFP_B 0x1584
-#define I40E_DEV_ID_QSFP_C 0x1585
-#define I40E_DEV_ID_10G_BASE_T 0x1586
-#define I40E_DEV_ID_20G_KR2 0x1587
-#define I40E_DEV_ID_20G_KR2_A 0x1588
-#define I40E_DEV_ID_10G_BASE_T4 0x1589
-#define I40E_DEV_ID_X722_A0 0x374C
-#define I40E_DEV_ID_KX_X722 0x37CE
-#define I40E_DEV_ID_QSFP_X722 0x37CF
-#define I40E
[dpdk-dev] [PATCH v3 04/13] fm10k: move pci device ids to driver
Since the base driver already defines all pci device ids, no need to
redefine them, let's just drop the previous RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/fm10k/fm10k_ethdev.c| 7 +++---
lib/librte_eal/common/include/rte_pci_dev_ids.h | 29 -
2 files changed, 4 insertions(+), 32 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 146bc2a..40b57f9 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -3018,9 +3018,10 @@ eth_fm10k_dev_uninit(struct rte_eth_dev *dev)
* and SRIOV-VF devices.
*/
static const struct rte_pci_id pci_id_fm10k_map[] = {
-#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
-#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_PF) },
+ { RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID,
+ FM10K_DEV_ID_SDI_FM10420_QDA2) },
+ { RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_VF) },
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index f1f3e13..a19fdfa 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -97,14 +97,6 @@
#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_FM10K
-#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_FM10KVF
-#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_ENIC
#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
#endif
@@ -117,11 +109,6 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#endif
-#ifndef PCI_VENDOR_ID_INTEL
-/** Vendor ID used by Intel devices */
-#define PCI_VENDOR_ID_INTEL 0x8086
-#endif
-
#ifndef PCI_VENDOR_ID_QUMRANET
/** Vendor ID used by virtio devices */
#define PCI_VENDOR_ID_QUMRANET 0x1AF4
@@ -142,14 +129,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/*** Physical FM10K devices from fm10k_type.h ***/
-
-#define FM10K_DEV_ID_PF 0x15A4
-#define FM10K_DEV_ID_SDI_FM10420_QDA2 0x15D0
-
-RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_PF)
-RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_SDI_FM10420_QDA2)
-
/** Virtio devices from virtio.h **/
#define QUMRANET_DEV_ID_VIRTIO 0x1000
@@ -162,12 +141,6 @@ RTE_PCI_DEV_ID_DECL_VIRTIO(PCI_VENDOR_ID_QUMRANET,
QUMRANET_DEV_ID_VIRTIO)
RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3)
-/*** Virtual FM10K devices from fm10k_type.h ***/
-
-#define FM10K_DEV_ID_VF 0x15A5
-
-RTE_PCI_DEV_ID_DECL_FM10KVF(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_VF)
-
/** Cisco VIC devices **/
#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
@@ -228,5 +201,3 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM,
BNX2X_DEV_ID_57840_MF)
#undef RTE_PCI_DEV_ID_DECL_BNX2XVF
#undef RTE_PCI_DEV_ID_DECL_VIRTIO
#undef RTE_PCI_DEV_ID_DECL_VMXNET3
-#undef RTE_PCI_DEV_ID_DECL_FM10K
-#undef RTE_PCI_DEV_ID_DECL_FM10KVF
--
1.9.1
[dpdk-dev] [PATCH v3 05/13] virtio: move pci device ids to driver
Reused defines from virtio_pci.h.
Signed-off-by: David Marchand
---
drivers/net/virtio/virtio_ethdev.c | 7 ++-
lib/librte_eal/common/include/rte_pci_dev_ids.h | 17 -
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index f8cc158..ee95cab 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -102,11 +102,8 @@ static int virtio_dev_queue_stats_mapping_set(
* The set of PCI devices this driver supports
*/
static const struct rte_pci_id pci_id_virtio_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(VIRTIO_PCI_VENDORID, VIRTIO_PCI_DEVICEID_MIN) },
+ { .vendor_id = 0, /* sentinel */ },
};
struct rte_virtio_xstats_name_off {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index a19fdfa..448b5e1 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -68,7 +68,6 @@
* driver which is a para virtualization driver running in guest virtual
machine.
* The inclusion of these in an array built using this file depends on the
* definition of
- * RTE_PCI_DEV_ID_DECL_VIRTIO
* at the time when this file is included.
*
* In order to populate an array, the user of this file must define this macro:
@@ -89,10 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
-#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_VMXNET3
#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
#endif
@@ -109,11 +104,6 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#endif
-#ifndef PCI_VENDOR_ID_QUMRANET
-/** Vendor ID used by virtio devices */
-#define PCI_VENDOR_ID_QUMRANET 0x1AF4
-#endif
-
#ifndef PCI_VENDOR_ID_VMWARE
/** Vendor ID used by VMware devices */
#define PCI_VENDOR_ID_VMWARE 0x15AD
@@ -129,12 +119,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/** Virtio devices from virtio.h **/
-
-#define QUMRANET_DEV_ID_VIRTIO 0x1000
-
-RTE_PCI_DEV_ID_DECL_VIRTIO(PCI_VENDOR_ID_QUMRANET, QUMRANET_DEV_ID_VIRTIO)
-
/** VMware VMXNET3 devices **/
#define VMWARE_DEV_ID_VMXNET3 0x07B0
@@ -199,5 +183,4 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM,
BNX2X_DEV_ID_57840_MF)
*/
#undef RTE_PCI_DEV_ID_DECL_BNX2X
#undef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#undef RTE_PCI_DEV_ID_DECL_VIRTIO
#undef RTE_PCI_DEV_ID_DECL_VMXNET3
--
1.9.1
[dpdk-dev] [PATCH v3 06/13] vmxnet3: move pci device ids to driver
Moved vmware device ids macro since the driver had no such information.
Signed-off-by: David Marchand
---
drivers/net/vmxnet3/vmxnet3_ethdev.c| 9 -
lib/librte_eal/common/include/rte_pci_dev_ids.h | 16
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 375e681..e3cfee4 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -100,12 +100,11 @@ static void vmxnet3_process_events(struct vmxnet3_hw *);
/*
* The set of PCI devices this driver supports
*/
+#define PCI_VENDOR_ID_VMWARE 0x15AD
+#define VMWARE_DEV_ID_VMXNET3 0x07B0
static const struct rte_pci_id pci_id_vmxnet3_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 448b5e1..0ecff3c 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -88,10 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_VMXNET3
-#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_ENIC
#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
#endif
@@ -104,11 +100,6 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#endif
-#ifndef PCI_VENDOR_ID_VMWARE
-/** Vendor ID used by VMware devices */
-#define PCI_VENDOR_ID_VMWARE 0x15AD
-#endif
-
#ifndef PCI_VENDOR_ID_CISCO
/** Vendor ID used by Cisco VIC devices */
#define PCI_VENDOR_ID_CISCO 0x1137
@@ -119,12 +110,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/** VMware VMXNET3 devices **/
-
-#define VMWARE_DEV_ID_VMXNET3 0x07B0
-
-RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3)
-
/** Cisco VIC devices **/
#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
@@ -183,4 +168,3 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM,
BNX2X_DEV_ID_57840_MF)
*/
#undef RTE_PCI_DEV_ID_DECL_BNX2X
#undef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#undef RTE_PCI_DEV_ID_DECL_VMXNET3
--
1.9.1
[dpdk-dev] [PATCH v3 07/13] enic: move pci device ids to driver
Moved cisco vendor id since the driver had no such information.
Signed-off-by: David Marchand
---
drivers/net/enic/enic_ethdev.c | 13 +
lib/librte_eal/common/include/rte_pci_dev_ids.h | 17 -
2 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 7539811..0e26aa9 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -57,15 +57,12 @@
/*
* The set of PCI devices this driver supports
*/
+#define PCI_VENDOR_ID_CISCO 0x1137
static const struct rte_pci_id pci_id_enic_map[] = {
-#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#ifndef PCI_VENDOR_ID_CISCO
-#define PCI_VENDOR_ID_CISCO0x1137
-#endif
-#include "rte_pci_dev_ids.h"
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET)
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
-{.vendor_id = 0, /* Sentinal */},
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_CISCO,
+ PCI_DEVICE_ID_CISCO_VIC_ENET_VF) },
+ {.vendor_id = 0, /* sentinel */},
};
static int
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 0ecff3c..1c22c04 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -88,10 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_ENIC
-#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_BNX2X
#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev)
#endif
@@ -100,24 +96,11 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#endif
-#ifndef PCI_VENDOR_ID_CISCO
-/** Vendor ID used by Cisco VIC devices */
-#define PCI_VENDOR_ID_CISCO 0x1137
-#endif
-
#ifndef PCI_VENDOR_ID_BROADCOM
/** Vendor ID used by Broadcom devices */
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/** Cisco VIC devices **/
-
-#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
-#define PCI_DEVICE_ID_CISCO_VIC_ENET_VF 0x0071 /* enet SRIOV VF */
-
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET)
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
-
/** QLogic devices **/
/* Broadcom/QLogic BNX2X */
--
1.9.1
[dpdk-dev] [PATCH v3 08/13] bnx2x: move pci device ids to driver
Reused defines from the driver and moved broadcom vendor id macro.
Signed-off-by: David Marchand
---
drivers/net/bnx2x/bnx2x.c | 3 +-
drivers/net/bnx2x/bnx2x_ethdev.c| 21 +++--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 60 -
3 files changed, 18 insertions(+), 66 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 6edb2f9..8264a74 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -22,7 +22,6 @@
#include "ecore_init_ops.h"
#include "rte_version.h"
-#include "rte_pci_dev_ids.h"
#include
#include
@@ -9588,7 +9587,7 @@ void bnx2x_load_firmware(struct bnx2x_softc *sc)
int f;
struct stat st;
- fwname = sc->devinfo.device_id == BNX2X_DEV_ID_57711
+ fwname = sc->devinfo.device_id == CHIP_NUM_57711
? FW_NAME_57711 : FW_NAME_57810;
f = open(fwname, O_RDONLY);
if (f < 0) {
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index ba194b5..06a0add 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -16,15 +16,28 @@
/*
* The set of PCI devices this driver supports
*/
+#define PCI_VENDOR_ID_BROADCOM 0x14E4
static struct rte_pci_id pci_id_bnx2x_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57711) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_OBS) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_4_10) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_2_20) },
+#ifdef RTE_LIBRTE_BNX2X_MF_SUPPORT
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810_MF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811_MF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_MF) },
+#endif
{ .vendor_id = 0, }
};
static struct rte_pci_id pci_id_bnx2xvf_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_VF) },
{ .vendor_id = 0, }
};
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 1c22c04..6720b7a 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -88,66 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_BNX2X
-#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
-#endif
-
-#ifndef PCI_VENDOR_ID_BROADCOM
-/** Vendor ID used by Broadcom devices */
-#define PCI_VENDOR_ID_BROADCOM 0x14E4
-#endif
-
-/** QLogic devices **/
-
-/* Broadcom/QLogic BNX2X */
-#define BNX2X_DEV_ID_57710 0x164e
-#define BNX2X_DEV_ID_57711 0x164f
-#define BNX2X_DEV_ID_57711E0x1650
-#define BNX2X_DEV_ID_57712 0x1662
-#define BNX2X_DEV_ID_57712_MF 0x1663
-#define BNX2X_DEV_ID_57712_VF 0x166f
-#define BNX2X_DEV_ID_57713 0x1651
-#define BNX2X_DEV_ID_57713E0x1652
-#define BNX2X_DEV_ID_57800 0x168a
-#define BNX2X_DEV_ID_57800_MF 0x16a5
-#define BNX2X_DEV_ID_57800_VF 0x16a9
-#define BNX2X_DEV_ID_57810 0x168e
-#define BNX2X_DEV_ID_57810_MF 0x16ae
-#define BNX2X_DEV_ID_57810_VF 0x16af
-#define BNX2X_DEV_ID_57811 0x163d
-#define BNX2X_DEV_ID_57811_MF 0x163e
-#define BNX2X_DEV_ID_57811_VF 0x163f
-
-#define BNX2X_DEV_ID_57840_OBS 0x168d
-#define BNX2X_DEV_ID_57840_OBS_MF 0x16ab
-#define BNX2X_DEV_ID_57840_4_100x16a1
-#define BNX2X_DEV_ID_57840_2_200x16a2
-#define BNX2X_DEV_ID_57840_MF 0x16a4
-#define BNX2X_DEV_ID_57840_VF 0x16ad
-
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800_VF)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57711)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810_VF)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811_VF)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57840_OBS)
-RTE
[dpdk-dev] [PATCH v3 09/13] ena: remove unneeded pci macro
I suppose this is a remnant of rte_pci_dev_ids.h, just remove this.
Signed-off-by: David Marchand
---
drivers/net/ena/ena_ethdev.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 2b60a67..efa5e31 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -80,11 +80,9 @@
#define PCI_DEVICE_ID_ENA_LLQ_VF 0xEC21
static struct rte_pci_id pci_id_ena_map[] = {
-#define RTE_PCI_DEV_ID_DECL_ENA(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-
- RTE_PCI_DEV_ID_DECL_ENA(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF)
- RTE_PCI_DEV_ID_DECL_ENA(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF)
- {.device_id = 0},
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF) },
+ { .device_id = 0 },
};
static int ena_device_init(struct ena_com_dev *ena_dev,
--
1.9.1
[dpdk-dev] [PATCH v3 10/13] pci: no need for global device ids list
Now that all pci device ids are in their respective drivers, we can remove this header. Signed-off-by: David Marchand --- doc/api/doxy-api-index.md | 1 - lib/librte_eal/common/Makefile | 2 +- lib/librte_eal/common/include/rte_pci_dev_ids.h | 93 - 3 files changed, 1 insertion(+), 95 deletions(-) delete mode 100644 lib/librte_eal/common/include/rte_pci_dev_ids.h diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index f626386..6b0ea11 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -45,7 +45,6 @@ There are many libraries, so their headers may be grouped by topics: [vhost] (@ref rte_virtio_net.h), [KNI](@ref rte_kni.h), [PCI](@ref rte_pci.h), - [PCI IDs](@ref rte_pci_dev_ids.h) - **memory**: [memseg] (@ref rte_memory.h), diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile index f5ea0ee..bb9810d 100644 --- a/lib/librte_eal/common/Makefile +++ b/lib/librte_eal/common/Makefile @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk INC := rte_branch_prediction.h rte_common.h INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h INC += rte_log.h rte_memory.h rte_memzone.h rte_pci.h -INC += rte_pci_dev_ids.h rte_per_lcore.h rte_random.h +INC += rte_per_lcore.h rte_random.h INC += rte_tailq.h rte_interrupts.h rte_alarm.h INC += rte_string_fns.h rte_version.h INC += rte_eal_memconfig.h rte_malloc_heap.h diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h b/lib/librte_eal/common/include/rte_pci_dev_ids.h deleted file mode 100644 index 6720b7a..000 --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h +++ /dev/null @@ -1,93 +0,0 @@ -/*- - * This file is provided under a dual BSD/GPLv2 license. When using or - * redistributing this file, you may do so under either license. - * - * GPL LICENSE SUMMARY - * - * Copyright(c) 2010-2015 Intel Corporation. All rights reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of version 2 of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. - * The full GNU General Public License is included in this distribution - * in the file called LICENSE.GPL. - * - * Contact Information: - * Intel Corporation - * - * BSD LICENSE - * - * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of Intel Corporation nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - */ - -/** - * @file - * - * This file contains a list of the PCI device IDs recognised by DPDK, which - * can be used to fill out an array of structures describing the devices. - * - * Currently four families of devices are recognised: those supported by the - * IGB driver, by EM driver, those supported by the IXGBE driver, and by virtio - * driver which is a para vir
[dpdk-dev] [PATCH v3 11/13] drivers: constify pci id tables
Signed-off-by: David Marchand
---
drivers/crypto/qat/rte_qat_cryptodev.c | 2 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++--
drivers/net/cxgbe/cxgbe_ethdev.c | 2 +-
drivers/net/ena/ena_ethdev.c | 2 +-
drivers/net/nfp/nfp_net.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c
b/drivers/crypto/qat/rte_qat_cryptodev.c
index 54f0c95..bce962f 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -67,7 +67,7 @@ static struct rte_cryptodev_ops crypto_qat_ops = {
* The set of PCI devices this driver supports
*/
-static struct rte_pci_id pci_id_qat_map[] = {
+static const struct rte_pci_id pci_id_qat_map[] = {
{
.vendor_id = 0x8086,
.device_id = 0x0443,
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 06a0add..a94b2e2 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -17,7 +17,7 @@
* The set of PCI devices this driver supports
*/
#define PCI_VENDOR_ID_BROADCOM 0x14E4
-static struct rte_pci_id pci_id_bnx2x_map[] = {
+static const struct rte_pci_id pci_id_bnx2x_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57711) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810) },
@@ -33,7 +33,7 @@ static struct rte_pci_id pci_id_bnx2x_map[] = {
{ .vendor_id = 0, }
};
-static struct rte_pci_id pci_id_bnx2xvf_map[] = {
+static const struct rte_pci_id pci_id_bnx2xvf_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800_VF) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810_VF) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811_VF) },
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 72b1a7b..919b4b7 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -68,7 +68,7 @@
* Macros needed to support the PCI Device ID Table ...
*/
#define CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN \
- static struct rte_pci_id cxgb4_pci_tbl[] = {
+ static const struct rte_pci_id cxgb4_pci_tbl[] = {
#define CH_PCI_DEVICE_ID_FUNCTION 0x4
#define PCI_VENDOR_ID_CHELSIO 0x1425
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index efa5e31..2f53d84 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -79,7 +79,7 @@
#define PCI_DEVICE_ID_ENA_VF 0xEC20
#define PCI_DEVICE_ID_ENA_LLQ_VF 0xEC21
-static struct rte_pci_id pci_id_ena_map[] = {
+static const struct rte_pci_id pci_id_ena_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF) },
{ .device_id = 0 },
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index baa840e..33256c9 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2455,7 +2455,7 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
return 0;
}
-static struct rte_pci_id pci_id_nfp_net_map[] = {
+static const struct rte_pci_id pci_id_nfp_net_map[] = {
{
.vendor_id = PCI_VENDOR_ID_NETRONOME,
.device_id = PCI_DEVICE_ID_NFP6000_PF_NIC,
--
1.9.1
[dpdk-dev] [PATCH v3 12/13] drivers: export pci drivers
Signed-off-by: David Marchand
---
drivers/net/mlx4/mlx4.c | 1 +
drivers/net/mlx5/mlx5.c | 1 +
drivers/net/virtio/virtio_ethdev.c | 1 +
lib/librte_eal/common/include/rte_pci.h | 7 +++
4 files changed, 10 insertions(+)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 0c76e72..14fe9dd 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5789,6 +5789,7 @@ static struct eth_driver mlx4_driver = {
.dev_private_size = sizeof(struct priv)
};
+RTE_EAL_PCI_DRIVER_EXPORT(mlx4, mlx4_driver.pci_drv);
RTE_INIT(rte_mlx4_pmd_init);
static void
rte_mlx4_pmd_init(void)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index f6399fc..975bb3f 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -646,6 +646,7 @@ static struct eth_driver mlx5_driver = {
.dev_private_size = sizeof(struct priv)
};
+RTE_EAL_PCI_DRIVER_EXPORT(mlx5, mlx5_driver.pci_drv);
RTE_INIT(rte_mlx5_pmd_init);
static void
rte_mlx5_pmd_init(void)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index ee95cab..587ba60 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1211,6 +1211,7 @@ static struct eth_driver rte_virtio_pmd = {
.dev_private_size = sizeof(struct virtio_hw),
};
+RTE_EAL_PCI_DRIVER_EXPORT(virtio, rte_virtio_pmd.pci_drv);
RTE_INIT(rte_virtio_pmd_init);
static void
rte_virtio_pmd_init(void)
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 3bb1833..3095f94 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -497,12 +497,19 @@ void rte_eal_pci_dump(FILE *f);
void rte_eal_pci_register(struct rte_pci_driver *driver);
#define RTE_EAL_PCI_REGISTER(name, d) \
+RTE_EAL_PCI_DRIVER_EXPORT(name, d); \
RTE_INIT(pciinitfn_ ##name); \
static void pciinitfn_ ##name(void) \
{ \
rte_eal_pci_register(&d); \
}
+#define RTE_EAL_PCI_DRIVER_PREFIX "pcidriver_"
+
+#define RTE_EAL_PCI_DRIVER_EXPORT(name, d) \
+extern const typeof(d) *pcidriver_ ##name; \
+const typeof(d) *pcidriver_ ##name = &d
+
/**
* Unregister a PCI driver.
*
--
1.9.1
[dpdk-dev] [PATCH v3 13/13] app: introduce dpdk-obj-info tool
Export some useful information for startup scripts and debug. For now, only pci drivers are handled. Example for a static binary: marchand at gloops:~/git/dpdk$ ./build/app/dpdk-obj-info ./build/app/testpmd pci:driver=cxgbe,flags=needmapping,lsc pci:driver=cxgbe,id=vendor=1425,device=5400,subvendor=,subdevice= pci:driver=cxgbe,id=vendor=1425,device=5401,subvendor=,subdevice= pci:driver=cxgbe,id=vendor=1425,device=5402,subvendor=,subdevice= Example for a dso: marchand at gloops:~/git/dpdk$ ./build/app/dpdk-obj-info ./build/lib/librte_pmd_ixgbe.so pci:driver=ixgbe,flags=needmapping,lsc,detachable pci:driver=ixgbe,id=vendor=8086,device=10b6,subvendor=,subdevice= pci:driver=ixgbe,id=vendor=8086,device=1508,subvendor=,subdevice= pci:driver=ixgbe,id=vendor=8086,device=10c6,subvendor=,subdevice= Signed-off-by: David Marchand --- app/Makefile | 1 + app/dpdk-obj-info/Makefile| 45 + app/dpdk-obj-info/dpdk-obj-info.c | 188 ++ 3 files changed, 234 insertions(+) create mode 100644 app/dpdk-obj-info/Makefile create mode 100644 app/dpdk-obj-info/dpdk-obj-info.c diff --git a/app/Makefile b/app/Makefile index 1151e09..0461a35 100644 --- a/app/Makefile +++ b/app/Makefile @@ -37,5 +37,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += test-pipeline DIRS-$(CONFIG_RTE_TEST_PMD) += test-pmd DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_test DIRS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += proc_info +DIRS-y += dpdk-obj-info include $(RTE_SDK)/mk/rte.subdir.mk diff --git a/app/dpdk-obj-info/Makefile b/app/dpdk-obj-info/Makefile new file mode 100644 index 000..b0f4bc7 --- /dev/null +++ b/app/dpdk-obj-info/Makefile @@ -0,0 +1,45 @@ +# BSD LICENSE +# +# Copyright 2016 6WIND S.A. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of 6WIND S.A. nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +include $(RTE_SDK)/mk/rte.vars.mk + + +APP = dpdk-obj-info + +SRCS-y += dpdk-obj-info.c + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +LDLIBS += -lbfd --as-needed + +DEPDIRS-y += lib + +include $(RTE_SDK)/mk/rte.app.mk diff --git a/app/dpdk-obj-info/dpdk-obj-info.c b/app/dpdk-obj-info/dpdk-obj-info.c new file mode 100644 index 000..23c183d --- /dev/null +++ b/app/dpdk-obj-info/dpdk-obj-info.c @@ -0,0 +1,188 @@ +/*- + * BSD LICENSE + * + * Copyright 2016 6WIND S.A. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of 6WIND S.A. nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
[dpdk-dev] Couple of PMD questions
On Wed, Apr 20, 2016 at 4:35 AM, Andriy Berestovskyy wrote: > Hi Jay, > > On Tue, Apr 19, 2016 at 10:16 PM, Jay Rolette wrote: > > Should the driver error out in that case instead of only "sort of" > working? > > +1, we hit the same issue. Error or log message would help. > > > If I support a max frame size of 9216 bytes (exactly a 1K multiple to > make > > the NIC happy), then max_rx_pkt_len is going to be 9216 and > data_room_size > > will be 9216 + RTE_PKTMBUF_HEADROOM. > > Try to set max_rx_pkt_len <= 9K - 8 and mempool element size to 9K + > headroom + size of structures. > Thanks, Andriy. That makes sense given how the code + NIC are working. > > Is that check correct? > > Datasheet says: > The MFS does not include the 4 bytes of the VLAN header. Packets with > VLAN header can be as large as MFS + 4. When double VLAN is enabled, > the device adds 8 to the MFS for any packets. > Gotcha. Hopefully we can get the docs and example code up to where app developers don't need to crawl through driver source and NIC datasheets. That or have rte_pktmbuf_pool_create() take care of that sort of detail automatically. :-) Jay Regards, > Andriy >
[dpdk-dev] [PATCH 0/4] testpmd forwarding
Modify testpmd to allow stop, close, detach and attach of a port without stopping forwarding. Bernard Iremonger (4): testpmd: add function port_is_forwarding testpmd: don't update fwding config when attaching/detaching a port testpmd: check port is not forwarding in stop_port and close_port testpmd: reconfigure forwarding after changing portlist app/test-pmd/config.c | 26 ++--- app/test-pmd/testpmd.c | 53 -- app/test-pmd/testpmd.h | 3 ++- 3 files changed, 37 insertions(+), 45 deletions(-) -- 2.6.3
[dpdk-dev] [PATCH 3/4] testpmd: check port is not forwarding in stop_port and close_port
Add calls to port_is_forwarding function.
Remove checks on test_done variable.
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Signed-off-by: Bernard Iremonger
---
app/test-pmd/testpmd.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 5dc7bba..7ccafd3 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1268,11 +1268,6 @@ start_port(portid_t pid)
struct rte_port *port;
struct ether_addr mac_addr;
- if (test_done == 0) {
- printf("Please stop forwarding first\n");
- return -1;
- }
-
if (port_id_is_invalid(pid, ENABLED_WARN))
return 0;
@@ -1424,10 +1419,6 @@ stop_port(portid_t pid)
struct rte_port *port;
int need_check_link_status = 0;
- if (test_done == 0) {
- printf("Please stop forwarding first\n");
- return;
- }
if (dcb_test) {
dcb_test = 0;
dcb_config = 0;
@@ -1442,6 +1433,11 @@ stop_port(portid_t pid)
if (pid != pi && pid != (portid_t)RTE_PORT_ALL)
continue;
+ if (port_is_forwarding(pi) != 0) {
+ printf("Please remove port %d from forwarding
configuration.\n", pi);
+ continue;
+ }
+
port = &ports[pi];
if (rte_atomic16_cmpset(&(port->port_status), RTE_PORT_STARTED,
RTE_PORT_HANDLING) == 0)
@@ -1466,11 +1462,6 @@ close_port(portid_t pid)
portid_t pi;
struct rte_port *port;
- if (test_done == 0) {
- printf("Please stop forwarding first\n");
- return;
- }
-
if (port_id_is_invalid(pid, ENABLED_WARN))
return;
@@ -1480,6 +1471,11 @@ close_port(portid_t pid)
if (pid != pi && pid != (portid_t)RTE_PORT_ALL)
continue;
+ if (port_is_forwarding(pi) != 0) {
+ printf("Please remove port %d from forwarding
configuration.\n", pi);
+ continue;
+ }
+
port = &ports[pi];
if (rte_atomic16_cmpset(&(port->port_status),
RTE_PORT_CLOSED, RTE_PORT_CLOSED) == 1) {
--
2.6.3
[dpdk-dev] [PATCH 2/4] testpmd: don't update fwding config when attaching/detaching a port
Remove checks on test_done variable.
Remove code to update forwarding configuration.
Fixes: edab33b1c01d ("app/testpmd: support port hotplug")
Signed-off-by: Bernard Iremonger
---
app/test-pmd/testpmd.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 26a174c..5dc7bba 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1506,7 +1506,7 @@ close_port(portid_t pid)
void
attach_port(char *identifier)
{
- portid_t i, j, pi = 0;
+ portid_t pi = 0;
printf("Attaching a new port...\n");
@@ -1515,11 +1515,6 @@ attach_port(char *identifier)
return;
}
- if (test_done == 0) {
- printf("Please stop forwarding first\n");
- return;
- }
-
if (rte_eth_dev_attach(identifier, &pi))
return;
@@ -1529,16 +1524,6 @@ attach_port(char *identifier)
nb_ports = rte_eth_dev_count();
- /* set_default_fwd_ports_config(); */
- memset(fwd_ports_ids, 0, sizeof(fwd_ports_ids));
- i = 0;
- FOREACH_PORT(j, ports) {
- fwd_ports_ids[i] = j;
- i++;
- }
- nb_cfg_ports = nb_ports;
- nb_fwd_ports++;
-
ports[pi].port_status = RTE_PORT_STOPPED;
printf("Port %d is attached. Now total ports is %d\n", pi, nb_ports);
@@ -1548,7 +1533,6 @@ attach_port(char *identifier)
void
detach_port(uint8_t port_id)
{
- portid_t i, pi = 0;
char name[RTE_ETH_NAME_MAX_LEN];
printf("Detaching a port...\n");
@@ -1564,16 +1548,6 @@ detach_port(uint8_t port_id)
ports[port_id].enabled = 0;
nb_ports = rte_eth_dev_count();
- /* set_default_fwd_ports_config(); */
- memset(fwd_ports_ids, 0, sizeof(fwd_ports_ids));
- i = 0;
- FOREACH_PORT(pi, ports) {
- fwd_ports_ids[i] = pi;
- i++;
- }
- nb_cfg_ports = nb_ports;
- nb_fwd_ports--;
-
printf("Port '%s' is detached. Now total ports is %d\n",
name, nb_ports);
printf("Done\n");
--
2.6.3
[dpdk-dev] [PATCH 1/4] testpmd: add function port_is_forwarding
Add function port_is_forwarding to check whether
a port is forwarding or not.
Signed-off-by: Bernard Iremonger
---
app/test-pmd/config.c | 18 +-
app/test-pmd/testpmd.h | 3 ++-
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index b1bbec6..db6b52b 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -1565,6 +1565,22 @@ set_fwd_ports_number(uint16_t nb_pt)
(unsigned int) nb_fwd_ports);
}
+int
+port_is_forwarding(portid_t port_id)
+{
+ unsigned int i;
+
+ if (port_id_is_invalid(port_id, ENABLED_WARN))
+ return -1;
+
+ for (i = 0; i < nb_fwd_ports; i++) {
+ if (fwd_ports_ids[i] == port_id)
+ return 1;
+ }
+
+ return 0;
+}
+
void
set_nb_pkt_per_burst(uint16_t nb)
{
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 0f72ca1..aa4bdac 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -500,6 +500,7 @@ void set_fwd_lcores_number(uint16_t nb_lc);
void set_fwd_ports_list(unsigned int *portlist, unsigned int nb_pt);
void set_fwd_ports_mask(uint64_t portmask);
void set_fwd_ports_number(uint16_t nb_pt);
+int port_is_forwarding(portid_t port_id);
void rx_vlan_strip_set(portid_t port_id, int on);
void rx_vlan_strip_set_on_queue(portid_t port_id, uint16_t queue_id, int on);
--
2.6.3
[dpdk-dev] [PATCH 4/4] testpmd: reconfigure forwarding after changing portlist
Set nb_fwd_ports to zero on quit.
Check portlist has been set before displaying forwarding configuration.
Fixes: d3a274ce9dee ("app/testpmd: handle SIGINT and SIGTERM")
Fixes: af75078fece3 ("first public release")
Signed-off-by: Bernard Iremonger
---
app/test-pmd/config.c | 8 ++--
app/test-pmd/testpmd.c | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index db6b52b..ff040d1 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1424,8 +1424,10 @@ pkt_fwd_config_display(struct fwd_config *cfg)
void
fwd_config_display(void)
{
- fwd_config_setup();
- pkt_fwd_config_display(&cur_fwd_config);
+ if (cur_fwd_config.nb_fwd_ports)
+ pkt_fwd_config_display(&cur_fwd_config);
+ else
+ printf("Please set portlist first\n");
}
int
@@ -1529,6 +1531,8 @@ set_fwd_ports_list(unsigned int *portlist, unsigned int
nb_pt)
(unsigned int) nb_fwd_ports, nb_pt);
nb_fwd_ports = (portid_t) nb_pt;
}
+
+ fwd_config_setup();
}
void
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 7ccafd3..11e7fe0 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1560,6 +1560,7 @@ pmd_test_exit(void)
if (ports != NULL) {
no_link_check = 1;
+ nb_fwd_ports = 0;
FOREACH_PORT(pt_id, ports) {
printf("\nShutting down port %d...\n", pt_id);
fflush(stdout);
--
2.6.3
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
On Wed, Apr 20, 2016 at 02:43:44PM +0200, David Marchand wrote:
> test application and kni still want to know e1000 pci devices.
> So let's create headers in the driver that will be used by them.
>
> I wanted to reuse base/ headers, but because of some headaches trying to
> resolve
> macros redefinition collisions in kni (with ixgbe next commit), I left it as
> is.
>
> Signed-off-by: David Marchand
> ---
> app/test/Makefile | 3 +
> app/test/test_pci.c | 3 +-
> drivers/net/e1000/em_ethdev.c | 2 +-
> drivers/net/e1000/em_pci_dev_ids.h | 208 +++
> drivers/net/e1000/igb_ethdev.c | 4 +-
> drivers/net/e1000/igb_pci_dev_ids.h | 165 +++
> lib/librte_eal/common/include/rte_pci_dev_ids.h | 254
>
> lib/librte_eal/linuxapp/kni/Makefile| 1 +
> lib/librte_eal/linuxapp/kni/kni_misc.c | 4 +-
> 9 files changed, 384 insertions(+), 260 deletions(-)
> create mode 100644 drivers/net/e1000/em_pci_dev_ids.h
> create mode 100644 drivers/net/e1000/igb_pci_dev_ids.h
>
> diff --git a/app/test/Makefile b/app/test/Makefile
> index a4907d5..8a1f54c 100644
> --- a/app/test/Makefile
> +++ b/app/test/Makefile
> @@ -171,6 +171,9 @@ CFLAGS_test_memcpy_perf.o += -fno-var-tracking-assignments
> endif
> endif
>
> +# pci tests want to know some pci devices ids
> +CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/e1000
> +
> # this application needs libraries first
> DEPDIRS-y += lib drivers
>
> diff --git a/app/test/test_pci.c b/app/test/test_pci.c
> index 0ed357e..7215936 100644
> --- a/app/test/test_pci.c
> +++ b/app/test/test_pci.c
> @@ -77,8 +77,9 @@ struct rte_pci_id my_driver_id2[] = {
>
> /* IGB & EM NICS */
> #define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
> +#include
> #define RTE_PCI_DEV_ID_DECL_IGB(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
> -#include
> +#include
>
> { .vendor_id = 0, /* sentinel */ },
> };
> diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
> index 1f80c05..203a9e5 100644
> --- a/drivers/net/e1000/em_ethdev.c
> +++ b/drivers/net/e1000/em_ethdev.c
> @@ -139,7 +139,7 @@ static enum e1000_fc_mode em_fc_setting = e1000_fc_full;
> static const struct rte_pci_id pci_id_em_map[] = {
>
> #define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
> -#include "rte_pci_dev_ids.h"
> +#include "em_pci_dev_ids.h"
>
> {0},
> };
> diff --git a/drivers/net/e1000/em_pci_dev_ids.h
> b/drivers/net/e1000/em_pci_dev_ids.h
> new file mode 100644
> index 000..736a68e
> --- /dev/null
> +++ b/drivers/net/e1000/em_pci_dev_ids.h
> @@ -0,0 +1,208 @@
> +/*-
> + * This file is provided under a dual BSD/GPLv2 license. When using or
> + * redistributing this file, you may do so under either license.
> + *
> + * GPL LICENSE SUMMARY
> + *
> + * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * The full GNU General Public License is included in this distribution
> + * in the file called LICENSE.GPL.
> + *
> + * Contact Information:
> + * Intel Corporation
> + *
> + * BSD LICENSE
> + *
> + * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIR
[dpdk-dev] [PATCH] power: fix argument cannot be negative
Fix issue reported by Coverity.
Coverity ID 13269 & 13266:
Function strerror(errno) has built strings only for non-negative errno values.
for negative values of errno it describe error as "Unknown error -errno"
to be more descriptive i put string "channel not found" taken from header.
The negative argument will be interpreted as a very large unsigned value.
In send_msg: Negative value used as argument to a function expecting
a positive value (for example, size of buffer or allocation)
Fixes: 445c6528b55f ("power: common interface for guest and host")
Signed-off-by: Daniel Mrzyglod
---
lib/librte_power/guest_channel.c| 3 ++-
lib/librte_power/rte_power_kvm_vm.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/librte_power/guest_channel.c b/lib/librte_power/guest_channel.c
index d6b6d0a..c0d23d8 100644
--- a/lib/librte_power/guest_channel.c
+++ b/lib/librte_power/guest_channel.c
@@ -104,7 +104,8 @@ guest_channel_host_connect(const char *path, unsigned
lcore_id)
ret = guest_channel_send_msg(&pkt, lcore_id);
if (ret != 0) {
RTE_LOG(ERR, GUEST_CHANNEL, "Error on channel '%s'
communications "
- "test: %s\n", fd_path, strerror(ret));
+ "test: %s\n", fd_path, ret > 0 ? strerror(ret) :
+ "channel not connected");
goto error;
}
RTE_LOG(INFO, GUEST_CHANNEL, "Channel '%s' is now connected\n",
fd_path);
diff --git a/lib/librte_power/rte_power_kvm_vm.c
b/lib/librte_power/rte_power_kvm_vm.c
index 7bb2774..5d53e6a 100644
--- a/lib/librte_power/rte_power_kvm_vm.c
+++ b/lib/librte_power/rte_power_kvm_vm.c
@@ -106,7 +106,8 @@ send_msg(unsigned lcore_id, uint32_t scale_direction)
ret = guest_channel_send_msg(&pkt[lcore_id], lcore_id);
if (ret == 0)
return 1;
- RTE_LOG(DEBUG, POWER, "Error sending message: %s\n", strerror(ret));
+ RTE_LOG(DEBUG, POWER, "Error sending message: %s\n", ret > 0 ?
strerror(ret)
+ : "channel not connected");
return -1;
}
--
2.5.5
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
On Wed, Apr 20, 2016 at 3:29 PM, Neil Horman wrote:
>> +#ifndef RTE_PCI_DEV_ID_DECL_EM
>> +#define RTE_PCI_DEV_ID_DECL_EM(vend, dev)
>> +#endif
>> +
>> +#ifndef PCI_VENDOR_ID_INTEL
>> +/** Vendor ID used by Intel devices */
>> +#define PCI_VENDOR_ID_INTEL 0x8086
>> +#endif
>> +
> This is broken, PCI_VENDOR_ID_INTEL should be defined in a central location
> for
> all pci drivers, not redefined in every compilation unit. And you can likely
Well we can keep the vendors in a common header, but I don't see the benefit.
> just remvoe the RTE_PCI_DEV_ID_DECL_* macros from each patch and use the
> RTE_PCI_DEV macro, as all the DECL macros just evaluate to that anyway.
app/test/test_pci.c:#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev)
{RTE_PCI_DEVICE(vend, dev)},
lib/librte_eal/linuxapp/kni/kni_misc.c: #define
RTE_PCI_DEV_ID_DECL_IGB(vend, dev) case (dev):
All this stuff is because of pci tests and kni code.
>>
>
>> +
>> +#undef RTE_PCI_DEV_ID_DECL_EM
> Why are you undefining this here? Is it because its in a header file and
> you're
> concerned about multiple inclusion? You should use an ifdef guard instead, or
> just define all the device id's in the header and ennumerate the pci table in
> one of the C files for the driver. That should apply to all the patches in
> this
> series I think
Just moved the code.
--
David Marchand
[dpdk-dev] [PATCH 1/4] ixgbe: rearrange vector PMD code for x86
move SSE-dependent code to new file "ixgbe_rxtx_vec_sse.h"
Signed-off-by: Jianbo Liu
---
drivers/net/ixgbe/ixgbe_rxtx_vec.c | 369 +
drivers/net/ixgbe/ixgbe_rxtx_vec_sse.h | 408 +
2 files changed, 409 insertions(+), 368 deletions(-)
create mode 100644 drivers/net/ixgbe/ixgbe_rxtx_vec_sse.h
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index 5040704..064a00b 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
@@ -38,364 +38,7 @@
#include "ixgbe_ethdev.h"
#include "ixgbe_rxtx.h"
-#include
-
-#ifndef __INTEL_COMPILER
-#pragma GCC diagnostic ignored "-Wcast-qual"
-#endif
-
-static inline void
-ixgbe_rxq_rearm(struct ixgbe_rx_queue *rxq)
-{
- int i;
- uint16_t rx_id;
- volatile union ixgbe_adv_rx_desc *rxdp;
- struct ixgbe_rx_entry *rxep = &rxq->sw_ring[rxq->rxrearm_start];
- struct rte_mbuf *mb0, *mb1;
- __m128i hdr_room = _mm_set_epi64x(RTE_PKTMBUF_HEADROOM,
- RTE_PKTMBUF_HEADROOM);
- __m128i dma_addr0, dma_addr1;
-
- const __m128i hba_msk = _mm_set_epi64x(0, UINT64_MAX);
-
- rxdp = rxq->rx_ring + rxq->rxrearm_start;
-
- /* Pull 'n' more MBUFs into the software ring */
- if (rte_mempool_get_bulk(rxq->mb_pool,
-(void *)rxep,
-RTE_IXGBE_RXQ_REARM_THRESH) < 0) {
- if (rxq->rxrearm_nb + RTE_IXGBE_RXQ_REARM_THRESH >=
- rxq->nb_rx_desc) {
- dma_addr0 = _mm_setzero_si128();
- for (i = 0; i < RTE_IXGBE_DESCS_PER_LOOP; i++) {
- rxep[i].mbuf = &rxq->fake_mbuf;
- _mm_store_si128((__m128i *)&rxdp[i].read,
- dma_addr0);
- }
- }
- rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
- RTE_IXGBE_RXQ_REARM_THRESH;
- return;
- }
-
- /* Initialize the mbufs in vector, process 2 mbufs in one loop */
- for (i = 0; i < RTE_IXGBE_RXQ_REARM_THRESH; i += 2, rxep += 2) {
- __m128i vaddr0, vaddr1;
- uintptr_t p0, p1;
-
- mb0 = rxep[0].mbuf;
- mb1 = rxep[1].mbuf;
-
- /*
-* Flush mbuf with pkt template.
-* Data to be rearmed is 6 bytes long.
-* Though, RX will overwrite ol_flags that are coming next
-* anyway. So overwrite whole 8 bytes with one load:
-* 6 bytes of rearm_data plus first 2 bytes of ol_flags.
-*/
- p0 = (uintptr_t)&mb0->rearm_data;
- *(uint64_t *)p0 = rxq->mbuf_initializer;
- p1 = (uintptr_t)&mb1->rearm_data;
- *(uint64_t *)p1 = rxq->mbuf_initializer;
-
- /* load buf_addr(lo 64bit) and buf_physaddr(hi 64bit) */
- vaddr0 = _mm_loadu_si128((__m128i *)&(mb0->buf_addr));
- vaddr1 = _mm_loadu_si128((__m128i *)&(mb1->buf_addr));
-
- /* convert pa to dma_addr hdr/data */
- dma_addr0 = _mm_unpackhi_epi64(vaddr0, vaddr0);
- dma_addr1 = _mm_unpackhi_epi64(vaddr1, vaddr1);
-
- /* add headroom to pa values */
- dma_addr0 = _mm_add_epi64(dma_addr0, hdr_room);
- dma_addr1 = _mm_add_epi64(dma_addr1, hdr_room);
-
- /* set Header Buffer Address to zero */
- dma_addr0 = _mm_and_si128(dma_addr0, hba_msk);
- dma_addr1 = _mm_and_si128(dma_addr1, hba_msk);
-
- /* flush desc with pa dma_addr */
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr0);
- _mm_store_si128((__m128i *)&rxdp++->read, dma_addr1);
- }
-
- rxq->rxrearm_start += RTE_IXGBE_RXQ_REARM_THRESH;
- if (rxq->rxrearm_start >= rxq->nb_rx_desc)
- rxq->rxrearm_start = 0;
-
- rxq->rxrearm_nb -= RTE_IXGBE_RXQ_REARM_THRESH;
-
- rx_id = (uint16_t) ((rxq->rxrearm_start == 0) ?
-(rxq->nb_rx_desc - 1) : (rxq->rxrearm_start - 1));
-
- /* Update the tail pointer on the NIC */
- IXGBE_PCI_REG_WRITE(rxq->rdt_reg_addr, rx_id);
-}
-
-/* Handling the offload flags (olflags) field takes computation
- * time when receiving packets. Therefore we provide a flag to disable
- * the processing of the olflags field when they are not needed. This
- * gives improved performance, at the cost of losing the offload info
- * in the received packet
- */
-#ifdef RTE_IXGBE_RX_OLFLAGS_ENABLE
-
-#define VTAG_SHIFT (3)
-
-static inline void
-desc_to_olflags_v(__m128i descs[4], struct rte_mbuf **rx_pkts)
-{
- __m128i ptype0, ptype1, vtag0, vtag1;
- union {
- uint16_t e[4];
- uint64_t
[dpdk-dev] [PATCH 2/4] ixgbe: implement vector PMD for arm architecture
use ARM NEON intrinsic to implement ixgbe vPMD
Signed-off-by: Jianbo Liu
---
drivers/net/ixgbe/ixgbe_rxtx_vec.c | 4 +
drivers/net/ixgbe/ixgbe_rxtx_vec_neon.h | 371
2 files changed, 375 insertions(+)
create mode 100644 drivers/net/ixgbe/ixgbe_rxtx_vec_neon.h
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index 064a00b..9fcc956 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
@@ -38,7 +38,11 @@
#include "ixgbe_ethdev.h"
#include "ixgbe_rxtx.h"
+#ifdef RTE_ARCH_ARM64
+#include "ixgbe_rxtx_vec_neon.h"
+#else
#include "ixgbe_rxtx_vec_sse.h"
+#endif
/*
* vPMD receive routine, only accept(nb_pkts >= RTE_IXGBE_DESCS_PER_LOOP)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.h
b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.h
new file mode 100644
index 000..2f1e1ce
--- /dev/null
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec_neon.h
@@ -0,0 +1,371 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+
+#include "ixgbe_ethdev.h"
+#include "ixgbe_rxtx.h"
+
+#include
+
+#pragma GCC diagnostic ignored "-Wcast-qual"
+
+static inline void
+ixgbe_rxq_rearm(struct ixgbe_rx_queue *rxq)
+{
+ int i;
+ uint16_t rx_id;
+ volatile union ixgbe_adv_rx_desc *rxdp;
+ struct ixgbe_rx_entry *rxep = &rxq->sw_ring[rxq->rxrearm_start];
+ struct rte_mbuf *mb0, *mb1;
+ uint64x2_t dma_addr0, dma_addr1;
+ uint64x2_t zero = vdupq_n_u64(0);
+ uint64_t paddr;
+ uint8x8_t p;
+
+ rxdp = rxq->rx_ring + rxq->rxrearm_start;
+
+ /* Pull 'n' more MBUFs into the software ring */
+ if (unlikely(rte_mempool_get_bulk(rxq->mb_pool,
+ (void *)rxep,
+ RTE_IXGBE_RXQ_REARM_THRESH) < 0)) {
+ if (rxq->rxrearm_nb + RTE_IXGBE_RXQ_REARM_THRESH >=
+ rxq->nb_rx_desc) {
+ for (i = 0; i < RTE_IXGBE_DESCS_PER_LOOP; i++) {
+ rxep[i].mbuf = &rxq->fake_mbuf;
+ vst1q_u64((uint64_t *)&rxdp[i].read,
+ zero);
+ }
+ }
+ rte_eth_devices[rxq->port_id].data->rx_mbuf_alloc_failed +=
+ RTE_IXGBE_RXQ_REARM_THRESH;
+ return;
+ }
+
+ p = vld1_u8((uint8_t *)&rxq->mbuf_initializer);
+
+ /* Initialize the mbufs in vector, process 2 mbufs in one loop */
+ for (i = 0; i < RTE_IXGBE_RXQ_REARM_THRESH; i += 2, rxep += 2) {
+ mb0 = rxep[0].mbuf;
+ mb1 = rxep[1].mbuf;
+
+ /*
+* Flush mbuf with pkt template.
+* Data to be rearmed is 6 bytes long.
+* Though, RX will overwrite ol_flags that are coming next
+* anyway. So overwrite whole 8 bytes with one load:
+* 6 bytes of rearm_data plus first 2 bytes of ol_flags.
+*/
+ vst1_u8((uint8_t *)&mb0->rearm_data, p);
+ paddr = mb0->buf_physaddr + RTE_PKTMBUF_HEADROOM;
+ dma_addr0 = vsetq_lane_u64(paddr, zero, 0);
+ /* flush desc with pa dma_addr */
+
[dpdk-dev] [PATCH 3/4] ixgbe: enable ixgbe vector PMD on ARMv8a platform
Signed-off-by: Jianbo Liu --- config/defconfig_arm64-armv8a-linuxapp-gcc | 1 - 1 file changed, 1 deletion(-) diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc index 9abeca4..98cc054 100644 --- a/config/defconfig_arm64-armv8a-linuxapp-gcc +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc @@ -42,7 +42,6 @@ CONFIG_RTE_FORCE_INTRINSICS=y CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y -CONFIG_RTE_IXGBE_INC_VECTOR=n CONFIG_RTE_LIBRTE_IVSHMEM=n CONFIG_RTE_LIBRTE_FM10K_PMD=n CONFIG_RTE_LIBRTE_I40E_PMD=n -- 1.8.3.1
[dpdk-dev] [PATCH 4/4] maintainers: claim responsibility for ixgbe vector PMD on ARM
Signed-off-by: Jianbo Liu --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1953ea2..07a9a44 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -142,6 +142,7 @@ F: lib/librte_eal/common/include/arch/arm/*_64.h F: lib/librte_acl/acl_run_neon.* F: lib/librte_lpm/rte_lpm_neon.h F: lib/librte_hash/rte*_arm64.h +F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.h EZchip TILE-Gx M: Zhigang Lu -- 1.8.3.1
[dpdk-dev] Couple of PMD questions
On Wed, Apr 20, 2016 at 07:22:57AM -0500, Jay Rolette wrote: > On Wed, Apr 20, 2016 at 4:10 AM, Bruce Richardson < > bruce.richardson at intel.com> wrote: > > > On Tue, Apr 19, 2016 at 03:16:37PM -0500, Jay Rolette wrote: > > > In ixgbe_dev_rx_init(), there is this bit of code: > > > > > > /* > > >* Configure the RX buffer size in the BSIZEPACKET field of > > >* the SRRCTL register of the queue. > > >* The value is in 1 KB resolution. Valid values can be from > > >* 1 KB to 16 KB. > > >*/ > > > buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mb_pool) - > > > RTE_PKTMBUF_HEADROOM); > > > srrctl |= ((buf_size >> IXGBE_SRRCTL_BSIZEPKT_SHIFT) & > > > IXGBE_SRRCTL_BSIZEPKT_MASK); > > > > > > IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(rxq->reg_idx), srrctl); > > > > > > buf_size = (uint16_t) ((srrctl & IXGBE_SRRCTL_BSIZEPKT_MASK) << > > > IXGBE_SRRCTL_BSIZEPKT_SHIFT); > > > > > > /* It adds dual VLAN length for supporting dual VLAN */ > > > if (dev->data->dev_conf.rxmode.max_rx_pkt_len + > > > 2 * IXGBE_VLAN_TAG_SIZE > buf_size) > > > dev->data->scattered_rx = 1; > > > > > > > > > Couple of questions I have about it: > > > > > > 1) If the caller configured the MBUF memory pool data room size to be > > > something other than a multiple of 1K (+ RTE_PKTMBUF_HEADROOM), then the > > > driver ends up silently programming the NIC to use a smaller max RX size > > > than the caller specified. > > > > > > Should the driver error out in that case instead of only "sort of" > > working? > > > If not, it seems like it should be logging an error message. > > > > Well, it does log at the end of the whole rx init process what RX function > > is > > being used, so there is that. > > However, looking at it now, given that there is an explicit setting in the > > config > > to request scattered mode, I think you may be right and that we should > > error out > > here if scattered mode is needed and not set. It could help prevent > > unexpected > > problems with these drivers. > > > > +1. A hard fail at init if I've misconfigured things is much preferred to > something that mostly works for typical test cases and only fails on > corner/limit testing. > > > > > 2) Second question is about the "/* It adds dual VLAN length for > > supporting > > > dual VLAN */" bit... > > > > > > As I understand it, dev_conf.rxmode.max_rx_pkt_len is supposed to be set > > to > > > the max frame size you support (although it says it's only used if jumbo > > > frame is enabled). That same value is generally used when calculating the > > > size that mbuf elements should be created at. > > > > > > The description for the data_room_size parameter of > > > rte_pktmbuf_pool_create(): > > > > > > "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM." > > > > > > > > > If I support a max frame size of 9216 bytes (exactly a 1K multiple to > > make > > > the NIC happy), then max_rx_pkt_len is going to be 9216 and > > data_room_size > > > will be 9216 + RTE_PKTMBUF_HEADROOM. > > > > > > ixgbe_dev_rx_init() will calculate normalize that back to 9216, which > > will > > > fail the dual VLAN length check. The really nasty part about that is it > > has > > > a side-effect of enabling scattered RX regardless of the fact that I > > didn't > > > enable scattered RX in dev_conf.rxmode. > > > > > > The code in the e1000 PMD is similar, so nothing unique to ixgbe. > > > > > > Is that check correct? It seems wrong to be adding space for q-in-q on > > top > > > of your specified max frame size... > > > > The issue here is what the correct behaviour needs to be. If we have the > > user > > specify the maximum frame size including all vlan tags, then we hit the > > problem > > where we have to subtract the VLAN tag sizes when writing the value to the > > NIC. > > In that case, we will hit a problem where we get a e.g. 9210 byte frame - > > to > > reuse your example - without any VLAN tags, which will be rejected by the > > hardware as being oversized. If we don't do the subtraction, and we get the > > same 9210 byte packet with 2 VLAN tags on it, the hardware will accept it > > and > > then split it across multiple descriptors because the actual DMA size is > > 9218 bytes. > > > > As an app developer, I didn't realize the max frame size didn't include > VLAN tags. I expected max frame size to be the size of the ethernet frame > on the wire, which I would expect to include space used by any VLAN or MPLS > tags. > > Is there anything in the docs or example apps about that? I did some > digging as I was debugging this and didn't notice it, but entirely possible > I just missed it. > > > > I'm not sure there is a works-in-all-cases solution here. > > > > Andriy's suggestion seems like it points in the right direction. > > From an app developer point of view, I'd expect to have
[dpdk-dev] KNI port type in IP pipeline
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Moon-Sang Lee > Sent: Friday, April 15, 2016 8:13 AM > To: dev at dpdk.org > Subject: [dpdk-dev] KNI port type in IP pipeline > > According to pp. 145 of DPDK programmer's guide 2.2.0, the KNI port type is > described in > table 23.1. But, I cannot find any material about how to specify the KNI > port type in pipeline > configuration file. > > Unfortunately, it seems there is no related source file in > $DPDK_TOP/lib/librte_port. > > Does packet framework already implement the KNI port type somewhere > or should I implement that KNI port type by myself? > > regards, > > > > -- > Moon-Sang Lee, SW Engineer > Email: sang0627 at gmail.com > Wisdom begins in wonder. *Socrates* Hi, There is no KNI or TUN/TAP port implemented in librte_port currently, hence please consider contributing this to DPDK. If the throughput of this device is not the first priority for you, I would actually recommend the TUN/TAP approach rather than KNI, as KNI seem to require significant maintenance due to constant changes in kernel header files, while TUN/TAP is very stable. KNI and TUN/TAP could also be leveraged straight away by librte_port as rte_ethdev type of port if they would be made available as PMDs. I know there were some plans to make this happen, but for some reason looks like the plans did not become reality. Thanks, Cristian
[dpdk-dev] [PATCH v3 0/3] xen: netfront poll mode driver
On Tue, Mar 22, 2016 at 10:55:26AM +0100, Jan Blunck wrote: > v3 changes: > - removed fake PCI interface > - removed struct virt_eth_driver > - check for UIO name and version > - added basic documentation > > Jan Blunck (3): > xen: Add UIO kernel driver > xen: Add netfront poll mode driver > xen: Add documentation > Hi Jan, any update on this series? /Bruce
[dpdk-dev] perfomance of rte_lpm rule subsystem
>I just realizied that my patch could be confusing. I want to emphasize that it >contains two completly different and independent set of changes. One is new >rule subsystem and the other is 64 bit next hop. Maybe I should've prepared a >patch with only rule changes, but I wanted to discuss fist and if there would >be interest spend some time and make the final patch containing only rule >changes. Normally if you have two or more distinct changes then you need split them up into different patch sets. Each change needs to be a complete patch and independent unless you have a order issue with the patches. > > >Please ignore the next hop changes. They have nothing to do with rule >subsystem changes. The rule changes don't need new next hop and I don't want >64 bit next hop to be part of dpdk. > >>> Hi. >>> >>> Doing some test with rte_lpm (adding/deleting bgp full table rules) I >>> noticed that >>> rule subsystem is very slow even considering that probably it was never >>> designed for using >>> in a data forwarding plane. So I want to propose some changes to the "rule" >>> subsystem. >>> >>> I reimplemented rule part ot the lib using rte_hash, and perfomance of >>> adding/deleted routes have increased dramatically. >>> If increasing speed of adding deleting routes makes sence for anybody else >>> I would like to discuss my patch. >>> The patch also include changes that make next_hop 64 bit, so please just >>> ignore them. The rule changes are in the following >>> functions only: >>> >>> rte_lpm2_create >>> >>> rule_find >>> rule_add >>> rule_delete >>> find_previous_rule >>> delete_depth_small >>> delete_depth_big >>> >>> rte_lpm2_add >>> rte_lpm2_delete >>> rte_lpm2_is_rule_present >>> rte_lpm2_delete_all > Regards, Keith
[dpdk-dev] [PATCH 0/3 v7] i40e: Add floating VEB support for i40e
On Fri, Mar 25, 2016 at 04:41:57PM +0800, Zhe Tao wrote: > This patch-set add the support for floating VEB in i40e. > All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or > the floating VEB. When connect to the floating VEB a new floating VEB is > created. Now all the VFs need to connect to floating VEB or legacy VEB, > cannot connect to both of them. The PF and VMDQ,FD VSIs connect to > the old legacy VEB/VEPA. > > All the VEB/VEPA concepts are not specific for FVL, they are defined in the > 802.1Qbg spec. > > This floating VEB only take effects on the specific version F/W. > > Zhe Tao (2): > Support floating VEB config > Add floating VEB support in i40e > Add global reset support for i40e > > doc/guides/nics/i40e.rst | 7 ++ > doc/guides/rel_notes/release_16_04.rst | 2 + > drivers/net/i40e/i40e_ethdev.c | 189 > + > drivers/net/i40e/i40e_ethdev.h | 38 +++ > drivers/net/i40e/i40e_pf.c | 11 +- > 5 files changed, 223 insertions(+), 24 deletions(-) > > V2: Added the release notes and changed commit log. > V3: Changed the VSI release operation. > V4: Added the FW version check otherwise it will cause the segment fault. > V5: Edited the code for new share code APIs > V6: Changed the floating VEB configuration method > V7: Added global reset for i40e BTW: When doing additional revisions of the patch, feel free to use the "-v N" parameter to "git format-patch", which will create the PATCH titles in the correct form for you. It's normal to have the v7,v8 etc. appear before the patch number in the series, not after as in your series. Regards, /Bruce
[dpdk-dev] [PATCH] ixgbe: checkpatch cleanups
On Fri, Apr 08, 2016 at 01:48:05AM +, Lu, Wenzhuo wrote: > Hi, > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger > > Sent: Friday, April 8, 2016 7:45 AM > > To: Zhang, Helin; Ananyev, Konstantin > > Cc: dev at dpdk.org; Stephen Hemminger > > Subject: [dpdk-dev] [PATCH] ixgbe: checkpatch cleanups > > > > Run ixgbe driver through checkpatch and edit away all the > > nasty bits. Fix line spacing, some bad indentation, and in a couple > > of cases use short circuit (already there) return to lessen indentation. > > > > Signed-off-by: Stephen Hemminger > Acked-by: Wenzhuo Lu Applied to dpdk-next-net/rel_16_07 with 4 additional checkpatch fixes included. /Bruce
[dpdk-dev] [PATCH v1] drivers/net/i40e: fix incorrect register dump offset
On Thu, Apr 14, 2016 at 03:08:07AM +, Wu, Jingjing wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Remy Horton
> > Sent: Wednesday, April 13, 2016 5:45 PM
> > To: Zhang, Helin
> > Cc: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v1] drivers/net/i40e: fix incorrect register dump
> > offset
> >
> > The position of register values within i40e register dumps is supposed to
> > reflect the register addresses. These were not being correctly calculated.
> >
> > Fixes: d9efd0136ac1 ("i40e: add EEPROM and registers dumping")
> >
> > Signed-off-by: Remy Horton
> Acked-by: Jingjing Wu
>
Applied to dpdk-next-net/rel_16_07
Thanks,
/Bruce
[dpdk-dev] [PATCH] examples/performance-thread: fix size of destination port ids in l3fwd-thread
After extending IPv4 next hop in lpm library, size of dst_port array was
changed from 16 to 32 bits in l3fwd-thread example, without modification
of the rest of path written for 16 bit value.
This patch uses similar approach for fix, like in commit 8353a36a9b4b
("examples/l3fwd: fix size of destination port ids"), restoring 16 bit size
for destination port ids and doing necessary conversion from 32 to 16 bit
after lpm_lookupx4.
Also fixes wrong logic in get_dst_port() on lpm path causing unpredictable
return value when ipv4/ipv6 lookup success, introduced in the same patch.
Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field")
Signed-off-by: Tomasz Kulasek
---
examples/performance-thread/l3fwd-thread/main.c | 45 ---
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/examples/performance-thread/l3fwd-thread/main.c
b/examples/performance-thread/l3fwd-thread/main.c
index 15c0a4d..6588c0c 100644
--- a/examples/performance-thread/l3fwd-thread/main.c
+++ b/examples/performance-thread/l3fwd-thread/main.c
@@ -1307,7 +1307,7 @@ l3fwd_simple_forward(struct rte_mbuf *m, uint8_t portid)
* to BAD_PORT value.
*/
static inline __attribute__((always_inline)) void
-rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint32_t *dp, uint32_t ptype)
+rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint16_t *dp, uint32_t ptype)
{
uint8_t ihl;
@@ -1326,7 +1326,7 @@ rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint32_t *dp,
uint32_t ptype)
}
#else
-#definerfc1812_process(mb, dp) do { } while (0)
+#definerfc1812_process(mb, dp, ptype) do { } while (0)
#endif /* DO_RFC_1812_CHECKS */
#endif /* APP_LOOKUP_LPM && ENABLE_MULTI_BUFFER_OPTIMIZE */
@@ -1343,28 +1343,27 @@ get_dst_port(struct rte_mbuf *pkt, uint32_t dst_ipv4,
uint8_t portid)
struct ether_hdr *eth_hdr;
if (RTE_ETH_IS_IPV4_HDR(pkt->packet_type)) {
- if
(rte_lpm_lookup(RTE_PER_LCORE(lcore_conf)->ipv4_lookup_struct,
- dst_ipv4, &next_hop_ipv4) != 0) {
- next_hop_ipv4 = portid;
- return next_hop_ipv4;
- }
+ return (uint16_t) ((rte_lpm_lookup(
+ RTE_PER_LCORE(lcore_conf)->ipv4_lookup_struct,
dst_ipv4,
+ &next_hop_ipv4) == 0) ? next_hop_ipv4 : portid);
+
} else if (RTE_ETH_IS_IPV6_HDR(pkt->packet_type)) {
+
eth_hdr = rte_pktmbuf_mtod(pkt, struct ether_hdr *);
ipv6_hdr = (struct ipv6_hdr *)(eth_hdr + 1);
- if
(rte_lpm6_lookup(RTE_PER_LCORE(lcore_conf)->ipv6_lookup_struct,
- ipv6_hdr->dst_addr, &next_hop_ipv6) != 0) {
- next_hop_ipv6 = portid;
- return next_hop_ipv6;
- }
- } else {
- next_hop_ipv4 = portid;
- return next_hop_ipv4;
+
+ return (uint16_t) ((rte_lpm6_lookup(
+ RTE_PER_LCORE(lcore_conf)->ipv6_lookup_struct,
+ ipv6_hdr->dst_addr, &next_hop_ipv6) == 0) ?
next_hop_ipv6 :
+ portid);
+
}
+ return portid;
}
static inline void
-process_packet(struct rte_mbuf *pkt, uint32_t *dst_port, uint8_t portid)
+process_packet(struct rte_mbuf *pkt, uint16_t *dst_port, uint8_t portid)
{
struct ether_hdr *eth_hdr;
struct ipv4_hdr *ipv4_hdr;
@@ -1431,9 +1430,9 @@ processx4_step1(struct rte_mbuf *pkt[FWDSTEP],
static inline void
processx4_step2(__m128i dip,
uint32_t ipv4_flag,
- uint32_t portid,
+ uint8_t portid,
struct rte_mbuf *pkt[FWDSTEP],
- uint32_t dprt[FWDSTEP])
+ uint16_t dprt[FWDSTEP])
{
rte_xmm_t dst;
const __m128i bswap_mask = _mm_set_epi8(12, 13, 14, 15, 8, 9, 10, 11,
@@ -1445,7 +1444,11 @@ processx4_step2(__m128i dip,
/* if all 4 packets are IPV4. */
if (likely(ipv4_flag)) {
rte_lpm_lookupx4(RTE_PER_LCORE(lcore_conf)->ipv4_lookup_struct,
dip,
- dprt, portid);
+ dst.u32, portid);
+
+ /* get rid of unused upper 16 bit for each dport. */
+ dst.x = _mm_packs_epi32(dst.x, dst.x);
+ *(uint64_t *)dprt = dst.u64[0];
} else {
dst.x = dip;
dprt[0] = get_dst_port(pkt[0], dst.u32[0], portid);
@@ -1460,7 +1463,7 @@ processx4_step2(__m128i dip,
* Perform RFC1812 checks and updates for IPV4 packets.
*/
static inline void
-processx4_step3(struct rte_mbuf *pkt[FWDSTEP], uint32_t dst_port[FWDSTEP])
+processx4_step3(struct rte_mbuf *pkt[FWDSTEP], uint16_t dst_port[FWDSTEP])
{
__m128i te[FWDSTEP];
__m128i ve[FWDSTEP];
@@ -1679,7 +1682,7 @@ process_burst(struct rte_mbuf *pkts_burst[MAX_PKT_BURST],
int nb_rx,
[dpdk-dev] Couple of PMD questions
On Wed, Apr 20, 2016 at 9:05 AM, Bruce Richardson < bruce.richardson at intel.com> wrote: > On Wed, Apr 20, 2016 at 07:22:57AM -0500, Jay Rolette wrote: > > On Wed, Apr 20, 2016 at 4:10 AM, Bruce Richardson < > > bruce.richardson at intel.com> wrote: > > > > > On Tue, Apr 19, 2016 at 03:16:37PM -0500, Jay Rolette wrote: > > > > In ixgbe_dev_rx_init(), there is this bit of code: > > > > > > > > /* > > > >* Configure the RX buffer size in the BSIZEPACKET field of > > > >* the SRRCTL register of the queue. > > > >* The value is in 1 KB resolution. Valid values can be from > > > >* 1 KB to 16 KB. > > > >*/ > > > > buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mb_pool) > - > > > > RTE_PKTMBUF_HEADROOM); > > > > srrctl |= ((buf_size >> IXGBE_SRRCTL_BSIZEPKT_SHIFT) & > > > > IXGBE_SRRCTL_BSIZEPKT_MASK); > > > > > > > > IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(rxq->reg_idx), srrctl); > > > > > > > > buf_size = (uint16_t) ((srrctl & IXGBE_SRRCTL_BSIZEPKT_MASK) << > > > > IXGBE_SRRCTL_BSIZEPKT_SHIFT); > > > > > > > > /* It adds dual VLAN length for supporting dual VLAN */ > > > > if (dev->data->dev_conf.rxmode.max_rx_pkt_len + > > > > 2 * IXGBE_VLAN_TAG_SIZE > buf_size) > > > > dev->data->scattered_rx = 1; > > > > > > > > > > > > Couple of questions I have about it: > > > > > > > > 1) If the caller configured the MBUF memory pool data room size to be > > > > something other than a multiple of 1K (+ RTE_PKTMBUF_HEADROOM), then > the > > > > driver ends up silently programming the NIC to use a smaller max RX > size > > > > than the caller specified. > > > > > > > > Should the driver error out in that case instead of only "sort of" > > > working? > > > > If not, it seems like it should be logging an error message. > > > > > > Well, it does log at the end of the whole rx init process what RX > function > > > is > > > being used, so there is that. > > > However, looking at it now, given that there is an explicit setting in > the > > > config > > > to request scattered mode, I think you may be right and that we should > > > error out > > > here if scattered mode is needed and not set. It could help prevent > > > unexpected > > > problems with these drivers. > > > > > > > +1. A hard fail at init if I've misconfigured things is much preferred to > > something that mostly works for typical test cases and only fails on > > corner/limit testing. > > > > > > > > 2) Second question is about the "/* It adds dual VLAN length for > > > supporting > > > > dual VLAN */" bit... > > > > > > > > As I understand it, dev_conf.rxmode.max_rx_pkt_len is supposed to be > set > > > to > > > > the max frame size you support (although it says it's only used if > jumbo > > > > frame is enabled). That same value is generally used when > calculating the > > > > size that mbuf elements should be created at. > > > > > > > > The description for the data_room_size parameter of > > > > rte_pktmbuf_pool_create(): > > > > > > > > "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM." > > > > > > > > > > > > If I support a max frame size of 9216 bytes (exactly a 1K multiple to > > > make > > > > the NIC happy), then max_rx_pkt_len is going to be 9216 and > > > data_room_size > > > > will be 9216 + RTE_PKTMBUF_HEADROOM. > > > > > > > > ixgbe_dev_rx_init() will calculate normalize that back to 9216, which > > > will > > > > fail the dual VLAN length check. The really nasty part about that is > it > > > has > > > > a side-effect of enabling scattered RX regardless of the fact that I > > > didn't > > > > enable scattered RX in dev_conf.rxmode. > > > > > > > > The code in the e1000 PMD is similar, so nothing unique to ixgbe. > > > > > > > > Is that check correct? It seems wrong to be adding space for q-in-q > on > > > top > > > > of your specified max frame size... > > > > > > The issue here is what the correct behaviour needs to be. If we have > the > > > user > > > specify the maximum frame size including all vlan tags, then we hit the > > > problem > > > where we have to subtract the VLAN tag sizes when writing the value to > the > > > NIC. > > > In that case, we will hit a problem where we get a e.g. 9210 byte > frame - > > > to > > > reuse your example - without any VLAN tags, which will be rejected by > the > > > hardware as being oversized. If we don't do the subtraction, and we > get the > > > same 9210 byte packet with 2 VLAN tags on it, the hardware will accept > it > > > and > > > then split it across multiple descriptors because the actual DMA size > is > > > 9218 bytes. > > > > > > > As an app developer, I didn't realize the max frame size didn't include > > VLAN tags. I expected max frame size to be the size of the ethernet frame > > on the wire, which I would expect to include space used by any VLAN or > MPLS > > tags. > > > > Is there anything i
[dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from xstats
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Remy Horton > Sent: Friday, April 15, 2016 10:44 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from > xstats > > The current extended ethernet statistics fetching involve doing several > string operations, which causes performance issues if there are lots of > statistics and/or network interfaces. This RFC patchset changes the API > for xstats to use integer identifiers instead of strings and implements > this new API for the ixgbe driver. Others drivers to follow. > > -- > > Since this will involve API & ABI breakage as previously advertised, there > are several design assumptions that need consideration: > > *) id-name & id-value pairs for both lookup and query Permits out-of-order > and non-contigious returning of names/ids/values, even though expected > implmentations would in practice return items in sorted order by id. Is > this sufficent/desirable future proofing? Idea is to allow possibility of > drivers returning partial statistics. I believe forcing drivers to match to a common id-space will become burdensome. If the stats id-space isn't common then matching strings is probably just as sufficient as long as drivers don't add/remove stats ad hoc between the time the device is initialized and removed. > > *) Bulk name-id mapping lookup only > At the moment individual lookup is not supported, as this would impose > extra overheads on drivers. The assumption is that any end user would > fetch all this data once on startup and then cache the mappings. I'm not sure I see the value of looking up a single stat from a user perspective. I can see where the drivers might say that some stats are less disruptive/etc but the user doesn't have that knowledge and wouldn't know how to take advantage. Usually all stats are grabbed multiple times and the changes noted during debug sessions. > > *) Replacement or additional API > This patch replaces the current xstats API, but there is no inherant > reason beyond maintainability why this funtionality could not be in > addition rather than a replacement. What is consensus on this? I came to the conclusion that replacing the existing API isn't necessary but rather extending it so backwards compatibility could be maintained during the previous discussions on this topic. However, if we want to go forward with cleaning up in order to reduce the support drivers provide I'm all for it. I still believe the API we develop should follow an "ethtool stats like" format as suggested earlier this year: extern int rte_eth_xstats_names_get(uint8_t port_id, struct rte_eth_xstats_name *names, unsigned n); extern int rte_eth_xstats_values_get(uint8_t port_id, uint64_t *values, unsigned n); Again, these could be provided alongside the existing API or replace it. I also like the idea you provided of a separate API to obtain the xstats count rather than deriving the count by calling one of the above functions with "dummy" values. Again, I can provide the patches for the changes I've made that align with this proposed API. I just never got any feedback on it when requested previously. Regards, Dave > > Comments welcome. > > Remy Horton (3): > rte: change xstats to use integer keys > drivers/net/ixgbe: change xstats to use integer keys > examples/ethtool: add xstats display command > > drivers/net/ixgbe/ixgbe_ethdev.c | 87 > +++ > examples/ethtool/ethtool-app/ethapp.c | 57 +++ > lib/librte_ether/rte_ethdev.c | 87 > +++ > lib/librte_ether/rte_ethdev.h | 38 +++ > 4 files changed, 252 insertions(+), 17 deletions(-) > > -- > 2.5.5
[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build
> >2016-04-20 00:14, Harish Patil: >> >2016-03-31 19:15, Rasesh Mody: >> >> --- a/config/common_base >> >> +++ b/config/common_base >> >> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24 >> >> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48 >> > >> >It looks to be some tuning which could be done at runtime. Isn't it? >> >> That?s right. Can you please suggest if there is any better option to >>make >> it a runtime? There is no PMD API for that. > >There are some devargs for that. >For PCI dev, it can be passed in the whitelist option. >We should remove this limitation by having a devargs API (and command line >options) independent of whitelisting. > Okay. For now, I?m okay to remove this config option till we find a way (either an API or command line option).
[dpdk-dev] [PATCH v5 10/10] qede: Enable PMD build
>On Wed, Apr 20, 2016 at 10:51:06AM +0200, Thomas Monjalon wrote: >> 2016-04-20 00:14, Harish Patil: >> > >2016-03-31 19:15, Rasesh Mody: >> > >> --- a/config/common_base >> > >> +++ b/config/common_base >> > >> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24 >> > >> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48 >> > > >> > >It looks to be some tuning which could be done at runtime. Isn't it? >> > >> > That?s right. Can you please suggest if there is any better option to >>make >> > it a runtime? There is no PMD API for that. >> >> There are some devargs for that. >> For PCI dev, it can be passed in the whitelist option. >> We should remove this limitation by having a devargs API (and command >>line >> options) independent of whitelisting. > >But back to the original setting. Are these likely to be values that are >tunable >or need to be tunable by the user? > This is a tunable which is equivalent of ethtool -c (in linux) which controls the rate at which status block is updated. >If not, I see little reason to make them >run-time configurable - they could be defines inside the driver itself. There are defines already which set them to the defaults. The reason to expose it as config option is that the user don?t have to change the driver and rather just control it via config file. For now, I can remove it till we find a better alternative to make those run time. Please confirm and I can have it removed in next patch submission. > >/Bruce >
[dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from xstats
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Harton > (dharton) > Sent: Wednesday, April 20, 2016 5:04 PM > To: Horton, Remy ; dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from > xstats > > > Again, I can provide the patches for the changes I've made that align with > this proposed API. I just never got any feedback on it when requested > previously. Hi David, Perhaps it would be good to submit your patches, also with an RFC tag, so we can make a comparison. Thanks, John. --
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
On Wed, Apr 20, 2016 at 03:39:59PM +0200, David Marchand wrote:
> On Wed, Apr 20, 2016 at 3:29 PM, Neil Horman wrote:
> >> +#ifndef RTE_PCI_DEV_ID_DECL_EM
> >> +#define RTE_PCI_DEV_ID_DECL_EM(vend, dev)
> >> +#endif
> >> +
> >> +#ifndef PCI_VENDOR_ID_INTEL
> >> +/** Vendor ID used by Intel devices */
> >> +#define PCI_VENDOR_ID_INTEL 0x8086
> >> +#endif
> >> +
> > This is broken, PCI_VENDOR_ID_INTEL should be defined in a central location
> > for
> > all pci drivers, not redefined in every compilation unit. And you can
> > likely
>
> Well we can keep the vendors in a common header, but I don't see the benefit.
>
?
The fact that you won't have to do this
#ifndef PCI_VENDOR_ID_INTEL
#define PCI_VENDOR_ID_INTEL ...
#endif
in every pmd
> > just remvoe the RTE_PCI_DEV_ID_DECL_* macros from each patch and use the
> > RTE_PCI_DEV macro, as all the DECL macros just evaluate to that anyway.
>
> app/test/test_pci.c:#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev)
> {RTE_PCI_DEVICE(vend, dev)},
> lib/librte_eal/linuxapp/kni/kni_misc.c: #define
> RTE_PCI_DEV_ID_DECL_IGB(vend, dev) case (dev):
>
> All this stuff is because of pci tests and kni code.
>
You're going to have to explain a bit further than that. Why does the kni code
and pci testing code require that each driver have their own macro that just
maps to the same macro underneath? Looking at the test_pci code, it appears its
done because we used to contain all our pci device ids in a single file, and the
device specific macros were used to selectively enable devices that were there
for testing. But the point of this series is in part to separate out the device
ids to their own locations, so it seems like you will have to fix up the pci
tests anyway (and additionally it would be nice to include more than just EM,
IGB, and IXGBE in thsoe tests anyway, though I understand thats outside the
scope of this series)
> >>
> >
> >> +
> >> +#undef RTE_PCI_DEV_ID_DECL_EM
> > Why are you undefining this here? Is it because its in a header file and
> > you're
> > concerned about multiple inclusion? You should use an ifdef guard instead,
> > or
> > just define all the device id's in the header and ennumerate the pci table
> > in
> > one of the C files for the driver. That should apply to all the patches in
> > this
> > series I think
>
> Just moved the code.
>
Ok, do you plan on cleaning that up?
Neil
>
> --
> David Marchand
>
[dpdk-dev] [PATCH] jobstats: Fix a typo in rte_jobstat.h.
jobstats: max_exec_time represents Maximum execute time and not
Minimum execute time.
Signed-off-by: Rami Rosen
---
lib/librte_jobstats/rte_jobstats.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_jobstats/rte_jobstats.h
b/lib/librte_jobstats/rte_jobstats.h
index c2b285f..b368603 100644
--- a/lib/librte_jobstats/rte_jobstats.h
+++ b/lib/librte_jobstats/rte_jobstats.h
@@ -85,7 +85,7 @@ struct rte_jobstats {
/**< Minimum execute time. */
uint64_t max_exec_time;
- /**< Minimum execute time. */
+ /**< Maximum execute time. */
uint64_t exec_cnt;
/**< Execute count. */
--
2.4.3
[dpdk-dev] [PATCH v3 3/7] drivers/net/bnxt new driver for Broadcom bnxt
> It's not for testing, more for code review and to help understand the code > [though > as you say, we do need to ensure that each commit doesn't actually break > the > build]. > Right now, the driver code goes in as a single commit - which makes it a > hard > enough task to review and see what is in there. One suggestion that > hopefully > wouldn't be too much work might be to split the code up into: basic device > init code, RX and TX functions, and then any additional features based on > top > of that [ideally one patch per added feature]. > The current driver doesn't have much beyond basic TX/RX, but we can give it a shot. "Too much work" is relative of course, but splitting it into self-contained easily understood chunks will absolutely be a lot of work. Adding Ajit who will also be working on this. Since he's coming up to speed on the driver code, this could be a good way for him to fully familiarize himself with it. -- Stephen Hurd
[dpdk-dev] [RFC PATCH 0/2] performance utility in testpmd
This RFC patch proposes a general purpose forwarding engine in testpmd namely "portfwd", to enable performance analysis and tuning for poll mode drivers in vSwitching scenarios. Problem statement - vSwitching is more I/O bound in a lot of cases since there are a lot of LLC/cross-core memory accesses. In order to reveal memory/cache behavior in real usage scenarios and enable efficient performance analysis and tuning for vSwitching, DPDK needs a sample application that supports traffic flow close to real deployment, e.g. multi-tenancy, service chaining. There is a vhost sample application currently to enable simple vSwitching scenarios, it comes with several limitations: 1) Traffic flow is too simple and not flexible 2) Switching based on MAC/VLAN only 3) Not enough performance metrics Proposed solution - The testpmd sample application is a good choice, it's a powerful poll mode driver management framework hosts various forwarding engine. Now with the vhost pmd feature, it can also handle vhost devices, only a new forwarding engine is needed to make use of it. portfwd is implemented to this end. Features of portfwd: 1) Build up traffic from simple rx/tx to complex scenarios easily 2) Rich performance statistics for all ports 3) Core affinity manipulation 4) Commands for run time configuration Notice that portfwd has fair performance, but it's not for getting the "maximum" numbers: 1) It buffers packets for burst send efficiency analysis, which increase latency 2) It touches the packet header and collect performance statistics which adds overheads These "extra" overheads are actually what happens in real applications. Several new commands are implemented for portfwd: 1) set fwd port switch forwarding engine to portfwd 2) show route show port info and forwarding rules for portfwd 3) set route packets from will be dispatched to 4) set route ip packets from will be dispatched based on dst ip 5) set ip set ip addr for , portfwd will use this ip addr to do ip route 6) set affinity forwarding stream will be handled by core (info can be read from "show route") 7) show port perf all show perf stats (rx/tx cycles, burst size distribution, tx pktloss) of each port 8) set drain set drain interval to drain buffered packets which is not sent because buffer not full (0 to disable) Implementation details -- To enable flexible traffic flow setup, each port has 2 ways to forward packets in portfwd: 1) Forward based on dst ip For ip based forwarding, portfwd scans each packet to get the dst ip for dst port mapping. A simple suffix mapping method is used for dst ip based forwarding, a macro IPV4_ROUTE_MASK is used to specify how many (last) bits of dst ip will be used for hashing. It is recommended to make sure there's no conflict by setting proper IPV4_ROUTE_MASK and/or different ip ends for each port, otherwise it may hurt performance. 2) Forward to a fixed port For fixed port forwarding, portfwd still scans each packet on purpose to simulate the impact of packet analysis behavior in real scenarios. After dst ports are identified, packets are enqueued to a buffer which will be burst sent when full. Packet buffers are built at each src port, so no contention at enqueue stage. There is a timeout interval to drain all buffers, which can be configured or disabled. Spinlock is used at dst port & queue to solve conflicts. Use case examples - Below are 3 examples to show how to use portfwd to build traffic flow in the host (Guest traffic can be built likewise): 1) PVP test: NIC-VM-NIC * 2 VMs each with 2 vhost ports: port 0, 1 and 2, 3 * 1 NIC with 2 ports: port 4, 5 * Traffic from 4 goes to 0 and 2, and back from 1, 3 to 5 Commands: set fwd port set ip 0 192 168 1 1 set ip 2 192 168 1 2 set route 4 ip (Make sure traffic has the right dst ip) set route 1 5 set route 3 5 set drain 0 show route 2) PVVP test: NIC-VM-VM-NIC * 2 VMs each with 2 vhost ports: port 0, 1 and 2, 3 * 1 NIC with 2 ports: port 4, 5 * Traffic from 4 goes to 0, and 1 to 2, finally 3 to 5 Commands: set fwd port set route 4 0 set route 1 2 set route 3 5 set drain 0 show route 3) PVP bi-directional test: NIC-VM-NIC * 1 VM with 2 vhost ports: port 0, 1 * 1 NIC with 2 ports: port 2, 3 * Traffic from 0 to 2, 1 to 3, and 2 to 0, 3 to 1 Commands: set fwd port set route 0 2 set route 2 0 set route 1 3 set route 3 1 set drain 0 show route For the PVP bi-direction
[dpdk-dev] [RFC PATCH 1/2] testpmd: add portfwd engine
This patch implements a general purpose forwarding engine in testpmd namely
"portfwd", to enable performance analysis and tuning for poll mode drivers
in vSwitching scenarios.
Features of portfwd:
1) Build up traffic from simple rx/tx to complex scenarios easily
2) Rich performance statistics for all ports
3) Core affinity manipulation
4) Commands for run time configuration
To enable flexible traffic flow setup, each port has 2 ways to forward
packets in portfwd:
1) Forward based on dst ip
For ip based forwarding, portfwd scans each packet to get the dst ip
for dst port mapping.
A simple suffix mapping method is used for dst ip based forwarding, a
macro IPV4_ROUTE_MASK is used to specify how many (last) bits of dst
ip will be used for hashing.
It is recommended to make sure there's no conflict by setting proper
IPV4_ROUTE_MASK and/or different ip ends for each port, otherwise it
may hurt performance.
2) Forward to a fixed port
For fixed port forwarding, portfwd still scans each packet on purpose
to simulate the impact of packet analysis behavior in real scenarios.
After dst ports are identified, packets are enqueued to a buffer which will
be burst sent when full. Packet buffers are built at each src port, so no
contention at enqueue stage.
There is a timeout interval to drain all buffers, which can be configured
or disabled.
Spinlock is used at dst port & queue to solve conflicts.
Notice that portfwd has fair performance, but it's not for getting the
"maximum" numbers:
1) It buffers packets for burst send efficiency analysis, which increase
latency
2) It touches the packet header and collect performance statistics which
adds overheads
These "extra" overheads are actually what happens in real applications.
Modifications are:
1) Add the portfwd engine in portfwd.c
2) Add related data structures
3) Add support functions
Signed-off-by: Zhihong Wang
---
app/test-pmd/Makefile | 1 +
app/test-pmd/config.c | 408 ++-
app/test-pmd/portfwd.c | 418 +
app/test-pmd/testpmd.c | 19 +++
app/test-pmd/testpmd.h | 62
5 files changed, 900 insertions(+), 8 deletions(-)
create mode 100644 app/test-pmd/portfwd.c
diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index 72426f3..0352feb 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -49,6 +49,7 @@ SRCS-y += parameters.c
SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline.c
SRCS-y += config.c
SRCS-y += iofwd.c
+SRCS-y += portfwd.c
SRCS-y += macfwd.c
SRCS-y += macfwd-retry.c
SRCS-y += macswap.c
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index b1bbec6..9754229 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -92,6 +92,8 @@
#include
#include
#include
+#include
+#include
#include "testpmd.h"
@@ -150,6 +152,11 @@ print_ethaddr(const char *name, struct ether_addr
*eth_addr)
void
nic_stats_display(portid_t port_id)
{
+ static uint64_t cnt_rx[RTE_MAX_ETHPORTS];
+ static uint64_t cnt_tx[RTE_MAX_ETHPORTS];
+ static uint64_t cycle[RTE_MAX_ETHPORTS];
+ uint64_t crx, ctx, c;
+
struct rte_eth_stats stats;
struct rte_port *port = &ports[port_id];
uint8_t i;
@@ -209,6 +216,20 @@ nic_stats_display(portid_t port_id)
}
}
+ c = cycle[port_id];
+ cycle[port_id] = rte_rdtsc();
+ if (c > 0)
+ c = cycle[port_id] - c;
+
+ crx = stats.ipackets - cnt_rx[port_id];
+ ctx = stats.opackets - cnt_tx[port_id];
+ cnt_rx[port_id] = stats.ipackets;
+ cnt_tx[port_id] = stats.opackets;
+ printf(" Throughput (since last show):\n");
+ printf(" RX PPS: %12"PRIu64"\n TX PPS: %12"PRIu64"\n",
+ c > 0 ? crx * rte_get_tsc_hz() / c : 0,
+ c > 0 ? ctx * rte_get_tsc_hz() / c : 0);
+
printf(" %s%s\n",
nic_stats_border, nic_stats_border);
}
@@ -1087,6 +1108,178 @@ setup_fwd_config_of_each_lcore(struct fwd_config *cfg)
}
static void
+copy_fwd_stream(struct fwd_stream *src, struct fwd_stream *dst)
+{
+ rte_memcpy(dst, src, sizeof(struct fwd_stream));
+}
+
+int
+set_fwd_stream_affinity(unsigned int idx, unsigned int core)
+{
+ struct fwd_stream **fwd_streams_tmp;
+ struct fwd_stream *fs;
+ unsigned int lc_id_dst;
+ unsigned int lc_id_src;
+ unsigned int fs_id;
+ unsigned int i, j, ci, cj;
+
+ if (cur_fwd_eng != &port_fwd_engine)
+ return 0;
+ if (test_done == 0) {
+ printf("please stop forwarding first\n");
+ return 0;
+ }
+ for (i = 0; i < cur_fwd_config.nb_fwd_lcores; i++) {
+ if (fwd_lcores_cpuids[i] == core) {
+ lc_id_dst = i;
+
[dpdk-dev] [RFC PATCH 2/2] testpmd: add portfwd commands
This patch adds command support for portfwd, to enable run time
configuration.
Command details:
1) set fwd port
switch forwarding engine to portfwd
2) show route
show port info and forwarding rules for portfwd
3) set route
packets from will be dispatched to
4) set route ip
packets from will be dispatched based on dst ip
5) set ip
set ip addr for , portfwd will use this ip addr to do ip
route
6) set affinity
forwarding stream will be handled by core
(info can be read from "show route")
7) show port perf all
show perf stats (rx/tx cycles, burst size distribution, tx pktloss)
of each port
8) set drain
set drain interval to drain buffered packets which is not sent
because buffer not full (0 to disable)
Below are 3 examples to show how to use portfwd to build traffic flow in
the host (Guest traffic can be built likewise):
1) PVP test: NIC-VM-NIC
* 2 VMs each with 2 vhost ports: port 0, 1 and 2, 3
* 1 NIC with 2 ports: port 4, 5
* Traffic from 4 goes to 0 and 2, and back from 1, 3 to 5
Commands:
set fwd port
set ip 0 192 168 1 1
set ip 2 192 168 1 2
set route 4 ip (Make sure traffic has the right dst ip)
set route 1 5
set route 3 5
set drain 0
show route
2) PVVP test: NIC-VM-VM-NIC
* 2 VMs each with 2 vhost ports: port 0, 1 and 2, 3
* 1 NIC with 2 ports: port 4, 5
* Traffic from 4 goes to 0, and 1 to 2, finally 3 to 5
Commands:
set fwd port
set route 4 0
set route 1 2
set route 3 5
set drain 0
show route
3) PVP bi-directional test: NIC-VM-NIC
* 1 VM with 2 vhost ports: port 0, 1
* 1 NIC with 2 ports: port 2, 3
* Traffic from 0 to 2, 1 to 3, and 2 to 0, 3 to 1
Commands:
set fwd port
set route 0 2
set route 2 0
set route 1 3
set route 3 1
set drain 0
show route
Signed-off-by: Zhihong Wang
---
app/test-pmd/cmdline.c | 279 -
1 file changed, 277 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index c5b9479..6a076a4 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -187,6 +187,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"show port (info|stats|xstats|fdir|stat_qmap|dcb_tc)
(port_id|all)\n"
"Display information for port_id, or all.\n\n"
+ "show port perf all\n"
+ "Display performance information for all.\n\n"
+
"show port X rss reta (size) (mask0,mask1,...)\n"
"Display the rss redirection table entry indicated"
" by masks on port X. size is used to indicate the"
@@ -5401,6 +5404,9 @@ static void cmd_showportall_parsed(void *parsed_result,
else if (!strcmp(res->what, "dcb_tc"))
FOREACH_PORT(i, ports)
port_dcb_info_display(i);
+ else if (!strcmp(res->what, "perf"))
+ if (cur_fwd_eng == &port_fwd_engine)
+ print_perf_stats();
}
cmdline_parse_token_string_t cmd_showportall_show =
@@ -5410,13 +5416,14 @@ cmdline_parse_token_string_t cmd_showportall_port =
TOKEN_STRING_INITIALIZER(struct cmd_showportall_result, port, "port");
cmdline_parse_token_string_t cmd_showportall_what =
TOKEN_STRING_INITIALIZER(struct cmd_showportall_result, what,
-"info#stats#xstats#fdir#stat_qmap#dcb_tc");
+
"info#stats#xstats#fdir#stat_qmap#dcb_tc#perf");
cmdline_parse_token_string_t cmd_showportall_all =
TOKEN_STRING_INITIALIZER(struct cmd_showportall_result, all, "all");
cmdline_parse_inst_t cmd_showportall = {
.f = cmd_showportall_parsed,
.data = NULL,
- .help_str = "show|clear port info|stats|xstats|fdir|stat_qmap|dcb_tc
all",
+ .help_str = "show|clear port info|stats|xstats|fdir|stat_qmap|"
+ "dcb_tc|perf all",
.tokens = {
(void *)&cmd_showportall_show,
(void *)&cmd_showportall_port,
@@ -9725,6 +9732,268 @@ cmdline_parse_inst_t cmd_mcast_addr = {
},
};
+/* *** SHOW ROUTE *** */
+struct cmd_show_route_result {
+ cmdline_fixed_string_t show;
+ cmdline_fixed_string_t route;
+};
+
+static void cmd_show_route_parsed(
+ __attribute__((unused)) void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ fwd_config_display();
+ print_port_info();
+ show_route();
+}
+
+cmdline_parse_token_string_t cmd_show_route_show =
+ TOKEN_STRING_INITIALIZER(stru
[dpdk-dev] Memory leak when adding/removing vhost_user ports
On Wed, Apr 20, 2016 at 08:18:49AM +0200, Christian Ehrhardt wrote: > On Wed, Apr 20, 2016 at 7:04 AM, Yuanhan Liu > wrote: > > On Tue, Apr 19, 2016 at 06:33:50PM +0200, Christian Ehrhardt wrote: > > [...]? > > > With that applied one (and only one) of my two guests looses > connectivity > after > > removing the ports the first time. > > Yeah, that's should be because I invoked the "->destroy_device()" > callback. > > > Shouldn't that not only destroy the particular vhost_user device I remove? I assume the "not" is typed wrong here, then yes. Well, it turned out that I accidentally destroyed the first guest (with id 0) with following code: ctx.fh = g_vhost_server.server[i]->fh; vhost_destroy_device(ctx); server[i]->fh is initialized with 0 when no connection is established (check below for more info), and the first id is started with 0. Anyway, this could be fixed easily. > See below for some better details on the test to clarify that. > > > BTW, I'm curious how do you do the test? I saw you added 256 ports, but > with 2 guests only? So, 254 of them are idle, just for testing the > memory leak bug? > > > Maybe I should describe it better: > 1. Spawn some vhost-user ports (40 in my case) > 2. Spawn a pair of guests that connect via four of those ports per guest > 3. Guests only intialize one of that vhost_user based NICs > 4. check connectivity between guests via the vhost_user based connection > (working at this stage) > LOOP 5-7: > ? ?5. add ports 41-512 > ? ?6. remove ?ports 41-512 > ? ?7. check connectivity between guests via the vhost_user based connection Yes, it's much clearer now. Thanks. I then don't see it's a leak from DPDK vhost-user, at least not the leak on "struct virtio_net" I have mentioned before. "struct virito_net" will not even be allocated for those ports never used (ports 41-512 in your case), as it will be allocated only when there is a connection established, aka, a guest is connected. BTW, will you be able to reproduce it without any connections? Say, all 512 ports are added, and then deleted. Thanks. --yliu > > So the vhost_user ports the guests are using are never deleted. > Only some extra (not even used) ports are added&removed in the loop to search > for potential leaks over a longer lifetime of an openvswitch-dpdk based > solution. >
