* Re: dpdk16.07 and virtio "Cannot mmap IO port resource"
From: Gopakumar Choorakkot Edakkunni @ 2016-12-10 23:21 UTC (permalink / raw)
To: dev, Olivier Matz
In-Reply-To: <CABK1yFDyLs4nzNPejCF=U63zdvcyFUNMEh0YX1F4z_RDzcwidg@mail.gmail.com>
Hi Oliver,
Looking at the kernel code pci_mmap_resource()--->pci_mmap_fits(), it looks
like pci_mmap_fits() expects that the "number of pages" requested to map is
no larger than the actual size of the pci resource. But in
pci_uio_ioport_map() what is passed as the requested size is the end_addr
of the resource, which in my case is 0xc09f, but the size of the resource
itself is 0x20 and hence kernel expects one page - but 0xc09f+1
(end_addr+1) gets translated to 13 pages ! And I guess that leads to the
mmap to fail .. Thoughts on this ?
Rgds,
Gopa.
On Fri, Dec 9, 2016 at 8:30 PM, Gopakumar Choorakkot Edakkunni <
gopakumar.c.e@gmail.com> wrote:
> I tried to load up dpdk (bound to uio_pci_generic, tried igb_uio also!) on
> a virtio interface. Dpdk exits with the "Cannot mmap IO port resource"
> complaint - the call chain is legacy_virtio_resource_init()-->pci_uio_ioport_map().
>
>
> If anyone can give any clues/pointers as to what might be wrong, that can
> greatly help in getting me on the right track fast !
>
> ---
> EAL: probe driver: 1af4:1000 rte_virtio_pmd
> EAL: PCI device 0000:00:05.0 on NUMA socket 0
> EAL: probe driver: 1af4:1000 r[ 330.753458] ------------[ cut here
> ]------------
> rte_virtio_pmd
> [ 330.754430] WARNING: CPU: 0 PID: 8063 at drivers/pci/pci-sysfs.c:984
> pci_mmap_resource.isra.14+0x113/0x1b0()
> [ 330.756083] process "dpdk_master" tried to map 0x0000d000 bytes at page
> 0x00000000 on 0000:00:05.0 BAR 0 (start 0x c080, size
> 0x 20)
> [ 330.758272] Modules linked in: rte_kni igb_uio pppoe ppp_async
> iptable_nat cdc_mbim sierra_net rndis_host qmi_wwan qcserial pppox
> ppp_generic option nf_nat_pptp nf_nat_ipv4 nf_nat_amanda nf_conntrack_pptp
> nf_conntrack_ipv4 nf_conntrack_amanda ipt_MASQUERADE huawei_cdc_ncm
> cdc_subset cdc_ncm cdc_ether cdc_eem ax88179_178a asix xt_u32 xt_time
> xt_tcpmss xt_string xt_statistic xt_state xt_socket xt_recent xt_quota
> xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit
> xt_length xt_iprange xt_id xt_hl xt_helper xt_hashlimit xt_esp xt_ecn
> xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment
> xt_addrtype xt_TPROXY xt_TEE xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_LED
> xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet usb_wwan ts_kmp ts_fsm ts_bm slhc
> sierra pl2303 nfnetlink_queue nfnetlink_log nf_nat_tftp nf_nat_snmp_basic
> nf_nat_sip nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat
> nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip
> nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_irc
> nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast
> lib80211_crypt_wep lib80211_crypt_tkip lib80211_crypt_ccmp lib80211
> iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ULOG ipt_REJECT
> ipt_ECN hso ftdi_sio crc8 crc7 crc_itu_t crc_ccitt cp210x cordic
> compat_xtables cdc_wdm cdc_acm arptable_filter arpt_mangle arp_tables
> sch_teql sch_tbf sch_sfq sch_red sch_prio sch_netem sch_htb sch_gred
> sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police
> act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex
> cls_flow cls_route cls_fw sch_hfsc sch_ingress evdev xt_NFQUEUE xt_set
> ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net
> ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport
> ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip
> ip_set nfnetlink sr_mod cdrom ip6t_REJECT ip6table_raw ip6table_mangle
> ip6table_filter ip6_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6
> ifb ipip ip6_tunnel tunnel6 tunnel4 ip_tunnel tun mdio loop vfat fat isofs
> nls_utf8 nls_iso8859_15 nls_iso8859_1 nls_cp850 nls_cp437 rfkill virtio_rng
> sha512_generic sha256_generic sha1_generic md5 arc4 ath10k_pci ath10k_core
> ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 compat pcnet32 e1000
> virtio_net ohci_hcd ixgbevf ixgbe hwmon igbvf igb dsa_core mii [last
> unloaded: igb_uio]
> [ 330.805110] CPU: 0 PID: 8063 Comm: dpdk_master Tainted: G W
> 3.14.67 #1
> [ 330.806104] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> Bochs 01/01/2011
> [ 330.806104] 0000000000000286 0000000000000000 ffffffff814e167c
> 0000000000000006
> [ 330.806104] ffff88008b573cd8 ffffffff81259d73 ffffffff81061b72
> ffff88013b24fae0
> [ 330.806104] ffff88013b24f800 0000000000000000 ffff88013a498000
> ffff88013b24f8a8
> [ 330.806104] Call Trace:
> [ 330.806104] [<ffffffff814e167c>] ? dump_stack+0x5e/0x7a
> [ 330.806104] [<ffffffff81259d73>] ? pci_mmap_resource.isra.14+0x11
> 3/0x1b0
> [ 330.806104] [<ffffffff81061b72>] ? warn_slowpath_common+0x82/0xb0
> [ 330.806104] [<ffffffff81061c55>] ? warn_slowpath_fmt+0x45/0x50
> [ 330.806104] [<ffffffff81120321>] ? do_last.isra.58+0xac1/0xc00
> [ 330.806104] [<ffffffff81259d73>] ? pci_mmap_resource.isra.14+0x11
> 3/0x1b0
> [ 330.806104] [<ffffffff8116da79>] ? kernfs_fop_mmap+0x69/0x100
> [ 330.806104] [<ffffffff810f4018>] ? mmap_region+0x2e8/0x560
> [ 330.806104] [<ffffffff810f45a8>] ? do_mmap_pgoff+0x318/0x3b0
> [ 330.806104] [<ffffffff810e1724>] ? vm_mmap_pgoff+0x74/0xc0
> [ 330.806104] [<ffffffff810f2d1a>] ? SyS_mmap_pgoff+0x18a/0x1e0
> [ 330.806104] [<ffffffff814e7759>] ? system_call_fastpath+0x16/0x1b
> [ 330.823897] ---[ end trace c6106b67c768d501 ]---
> EAL: Cannot mmap IO port resource: Invalid argument
> EAL: Error - exiting with code: 1
> Cause: Requested device 0000:00:05.0 cannot be used
>
^ permalink raw reply
* Re: dpdk16.07 and virtio "Cannot mmap IO port resource"
From: Gopakumar Choorakkot Edakkunni @ 2016-12-11 8:29 UTC (permalink / raw)
To: dev, Olivier Matz
In-Reply-To: <CABK1yFDSHOh3CRrNMoEZniTrk8JLW3XSpe2dvcuUsOynH2RXRQ@mail.gmail.com>
Somewhere I read that the "offset" parameter for sysfs mmap() needs to be
the start address of the resource, so I tried the below diff, and mmap
still fails .. Still scratching my head
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
index 1786b75..e882940 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
@@ -462,8 +462,8 @@ pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
strerror(errno));
goto error;
}
- addr = mmap(NULL, end_addr + 1, PROT_READ | PROT_WRITE,
- MAP_SHARED, fd, 0);
+ addr = mmap(NULL, (end_addr-phys_addr) + 1, PROT_READ | PROT_WRITE,
+ MAP_SHARED, fd, phys_addr);
close(fd);
if (addr == MAP_FAILED) {
RTE_LOG(ERR, EAL, "Cannot mmap IO port resource: %s\n",
@@ -473,7 +473,7 @@ pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
/* strangely, the base address is mmap addr + phys_addr */
p->base = (uintptr_t)addr + phys_addr;
- p->len = end_addr + 1;
+ p->len = (end_addr-phys_addr) + 1;
RTE_LOG(DEBUG, EAL, "PCI Port IO found start=0x%"PRIx64"\n",
p->base);
fclose(f);
On Sat, Dec 10, 2016 at 3:21 PM, Gopakumar Choorakkot Edakkunni <
gopakumar.c.e@gmail.com> wrote:
> Hi Oliver,
>
> Looking at the kernel code pci_mmap_resource()--->pci_mmap_fits(), it
> looks like pci_mmap_fits() expects that the "number of pages" requested to
> map is no larger than the actual size of the pci resource. But in
> pci_uio_ioport_map() what is passed as the requested size is the end_addr
> of the resource, which in my case is 0xc09f, but the size of the resource
> itself is 0x20 and hence kernel expects one page - but 0xc09f+1
> (end_addr+1) gets translated to 13 pages ! And I guess that leads to the
> mmap to fail .. Thoughts on this ?
>
> Rgds,
> Gopa.
>
>
> On Fri, Dec 9, 2016 at 8:30 PM, Gopakumar Choorakkot Edakkunni <
> gopakumar.c.e@gmail.com> wrote:
>
>> I tried to load up dpdk (bound to uio_pci_generic, tried igb_uio also!)
>> on a virtio interface. Dpdk exits with the "Cannot mmap IO port resource"
>> complaint - the call chain is legacy_virtio_resource_init()-->pci_uio_ioport_map().
>>
>>
>> If anyone can give any clues/pointers as to what might be wrong, that can
>> greatly help in getting me on the right track fast !
>>
>> ---
>> EAL: probe driver: 1af4:1000 rte_virtio_pmd
>> EAL: PCI device 0000:00:05.0 on NUMA socket 0
>> EAL: probe driver: 1af4:1000 r[ 330.753458] ------------[ cut here
>> ]------------
>> rte_virtio_pmd
>> [ 330.754430] WARNING: CPU: 0 PID: 8063 at drivers/pci/pci-sysfs.c:984
>> pci_mmap_resource.isra.14+0x113/0x1b0()
>> [ 330.756083] process "dpdk_master" tried to map 0x0000d000 bytes at
>> page 0x00000000 on 0000:00:05.0 BAR 0 (start 0x c080, size
>> 0x 20)
>> [ 330.758272] Modules linked in: rte_kni igb_uio pppoe ppp_async
>> iptable_nat cdc_mbim sierra_net rndis_host qmi_wwan qcserial pppox
>> ppp_generic option nf_nat_pptp nf_nat_ipv4 nf_nat_amanda nf_conntrack_pptp
>> nf_conntrack_ipv4 nf_conntrack_amanda ipt_MASQUERADE huawei_cdc_ncm
>> cdc_subset cdc_ncm cdc_ether cdc_eem ax88179_178a asix xt_u32 xt_time
>> xt_tcpmss xt_string xt_statistic xt_state xt_socket xt_recent xt_quota
>> xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit
>> xt_length xt_iprange xt_id xt_hl xt_helper xt_hashlimit xt_esp xt_ecn
>> xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment
>> xt_addrtype xt_TPROXY xt_TEE xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_LED
>> xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet usb_wwan ts_kmp ts_fsm ts_bm slhc
>> sierra pl2303 nfnetlink_queue nfnetlink_log nf_nat_tftp nf_nat_snmp_basic
>> nf_nat_sip nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat
>> nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip
>> nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_irc
>> nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast
>> lib80211_crypt_wep lib80211_crypt_tkip lib80211_crypt_ccmp lib80211
>> iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ULOG ipt_REJECT
>> ipt_ECN hso ftdi_sio crc8 crc7 crc_itu_t crc_ccitt cp210x cordic
>> compat_xtables cdc_wdm cdc_acm arptable_filter arpt_mangle arp_tables
>> sch_teql sch_tbf sch_sfq sch_red sch_prio sch_netem sch_htb sch_gred
>> sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police
>> act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex
>> cls_flow cls_route cls_fw sch_hfsc sch_ingress evdev xt_NFQUEUE xt_set
>> ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net
>> ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport
>> ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip
>> ip_set nfnetlink sr_mod cdrom ip6t_REJECT ip6table_raw ip6table_mangle
>> ip6table_filter ip6_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6
>> ifb ipip ip6_tunnel tunnel6 tunnel4 ip_tunnel tun mdio loop vfat fat isofs
>> nls_utf8 nls_iso8859_15 nls_iso8859_1 nls_cp850 nls_cp437 rfkill virtio_rng
>> sha512_generic sha256_generic sha1_generic md5 arc4 ath10k_pci ath10k_core
>> ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 compat pcnet32 e1000
>> virtio_net ohci_hcd ixgbevf ixgbe hwmon igbvf igb dsa_core mii [last
>> unloaded: igb_uio]
>> [ 330.805110] CPU: 0 PID: 8063 Comm: dpdk_master Tainted: G W
>> 3.14.67 #1
>> [ 330.806104] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS Bochs 01/01/2011
>> [ 330.806104] 0000000000000286 0000000000000000 ffffffff814e167c
>> 0000000000000006
>> [ 330.806104] ffff88008b573cd8 ffffffff81259d73 ffffffff81061b72
>> ffff88013b24fae0
>> [ 330.806104] ffff88013b24f800 0000000000000000 ffff88013a498000
>> ffff88013b24f8a8
>> [ 330.806104] Call Trace:
>> [ 330.806104] [<ffffffff814e167c>] ? dump_stack+0x5e/0x7a
>> [ 330.806104] [<ffffffff81259d73>] ? pci_mmap_resource.isra.14+0x11
>> 3/0x1b0
>> [ 330.806104] [<ffffffff81061b72>] ? warn_slowpath_common+0x82/0xb0
>> [ 330.806104] [<ffffffff81061c55>] ? warn_slowpath_fmt+0x45/0x50
>> [ 330.806104] [<ffffffff81120321>] ? do_last.isra.58+0xac1/0xc00
>> [ 330.806104] [<ffffffff81259d73>] ? pci_mmap_resource.isra.14+0x11
>> 3/0x1b0
>> [ 330.806104] [<ffffffff8116da79>] ? kernfs_fop_mmap+0x69/0x100
>> [ 330.806104] [<ffffffff810f4018>] ? mmap_region+0x2e8/0x560
>> [ 330.806104] [<ffffffff810f45a8>] ? do_mmap_pgoff+0x318/0x3b0
>> [ 330.806104] [<ffffffff810e1724>] ? vm_mmap_pgoff+0x74/0xc0
>> [ 330.806104] [<ffffffff810f2d1a>] ? SyS_mmap_pgoff+0x18a/0x1e0
>> [ 330.806104] [<ffffffff814e7759>] ? system_call_fastpath+0x16/0x1b
>> [ 330.823897] ---[ end trace c6106b67c768d501 ]---
>> EAL: Cannot mmap IO port resource: Invalid argument
>> EAL: Error - exiting with code: 1
>> Cause: Requested device 0000:00:05.0 cannot be used
>>
>
>
^ permalink raw reply related
* Re: [PATCH 1/4] eal/common: introduce rte_memset on IA platform
From: Yang, Zhiyong @ 2016-12-11 12:04 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev@dpdk.org, yuanhan.liu@linux.intel.com, Richardson, Bruce,
Ananyev, Konstantin, De Lara Guarch, Pablo
In-Reply-To: <2141223.ggdlk6O12s@xps13>
Hi, Thomas:
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, December 8, 2016 11:10 PM
> To: Yang, Zhiyong <zhiyong.yang@intel.com>
> Cc: dev@dpdk.org; yuanhan.liu@linux.intel.com; Richardson, Bruce
> <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Subject: Re: [dpdk-dev] [PATCH 1/4] eal/common: introduce rte_memset on
> IA platform
>
> 2016-12-08 07:41, Yang, Zhiyong:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2016-12-05 16:26, Zhiyong Yang:
> > > > +#ifndef _RTE_MEMSET_X86_64_H_
> > >
> > > Is this implementation specific to 64-bit?
> > >
> >
> > Yes.
>
> So should we rename this file?
> rte_memset.h -> rte_memset_64.h
>
> You need also to create a file rte_memset.h for each arch.
Ok
^ permalink raw reply
* Re: [PATCH 1/4] eal/common: introduce rte_memset on IA platform
From: Yang, Zhiyong @ 2016-12-11 12:32 UTC (permalink / raw)
To: Ananyev, Konstantin, Thomas Monjalon
Cc: dev@dpdk.org, yuanhan.liu@linux.intel.com, Richardson, Bruce,
De Lara Guarch, Pablo
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E568B@irsmsx105.ger.corp.intel.com>
Hi, Konstantin, Bruce:
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Thursday, December 8, 2016 6:31 PM
> To: Yang, Zhiyong <zhiyong.yang@intel.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Cc: dev@dpdk.org; yuanhan.liu@linux.intel.com; Richardson, Bruce
> <bruce.richardson@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Subject: RE: [dpdk-dev] [PATCH 1/4] eal/common: introduce rte_memset on
> IA platform
>
>
>
> > -----Original Message-----
> > From: Yang, Zhiyong
> > Sent: Thursday, December 8, 2016 9:53 AM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Thomas
> > Monjalon <thomas.monjalon@6wind.com>
> > Cc: dev@dpdk.org; yuanhan.liu@linux.intel.com; Richardson, Bruce
> > <bruce.richardson@intel.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>
> > Subject: RE: [dpdk-dev] [PATCH 1/4] eal/common: introduce rte_memset
> > on IA platform
> >
> > Hi， Konstantin:
> >
> > > -----Original Message-----
> > > From: Ananyev, Konstantin
> > > Sent: Thursday, December 8, 2016 5:26 PM
> > > To: Yang, Zhiyong <zhiyong.yang@intel.com>; Thomas Monjalon
> > > <thomas.monjalon@6wind.com>
> > > Cc: dev@dpdk.org; yuanhan.liu@linux.intel.com; Richardson, Bruce
> > > <bruce.richardson@intel.com>; De Lara Guarch, Pablo
> > > <pablo.de.lara.guarch@intel.com>
> > > Subject: RE: [dpdk-dev] [PATCH 1/4] eal/common: introduce rte_memset
> > > on IA platform
> > >
> > >
> > > Hi Zhiyong,
> > >
> > > >
> > > > HI, Thomas:
> > > > Sorry for late reply. I have been being always considering your
> > > suggestion.
> > > >
> > > > > -----Original Message-----
> > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > > > Sent: Friday, December 2, 2016 6:25 PM
> > > > > To: Yang, Zhiyong <zhiyong.yang@intel.com>
> > > > > Cc: dev@dpdk.org; yuanhan.liu@linux.intel.com; Richardson, Bruce
> > > > > <bruce.richardson@intel.com>; Ananyev, Konstantin
> > > > > <konstantin.ananyev@intel.com>; De Lara Guarch, Pablo
> > > > > <pablo.de.lara.guarch@intel.com>
> > > > > Subject: Re: [dpdk-dev] [PATCH 1/4] eal/common: introduce
> > > rte_memset
> > > > > on IA platform
> > > > >
> > > > > 2016-12-05 16:26, Zhiyong Yang:
> > > > > > +#ifndef _RTE_MEMSET_X86_64_H_
> > > > >
> > > > > Is this implementation specific to 64-bit?
> > > > >
> > > >
> > > > Yes.
> > > >
> > > > > > +
> > > > > > +#define rte_memset memset
> > > > > > +
> > > > > > +#else
> > > > > > +
> > > > > > +static void *
> > > > > > +rte_memset(void *dst, int a, size_t n);
> > > > > > +
> > > > > > +#endif
> > > > >
> > > > > If I understand well, rte_memset (as rte_memcpy) is using the
> > > > > most recent instructions available (and enabled) when compiling.
> > > > > It is not adapting the instructions to the run-time CPU.
> > > > > There is no need to downgrade at run-time the instruction set as
> > > > > it is obviously not a supported case, but it would be nice to be
> > > > > able to upgrade a "default compilation" at run-time as it is done in
> rte_acl.
> > > > > I explain this case more clearly for reference:
> > > > >
> > > > > We can have AVX512 supported in the compiler but disable it when
> > > > > compiling
> > > > > (CONFIG_RTE_MACHINE=snb) in order to build a binary running
> > > > > almost everywhere.
> > > > > When running this binary on a CPU having AVX512 support, it will
> > > > > not benefit of the AVX512 improvement.
> > > > > Though, we can compile an AVX512 version of some functions and
> > > > > use them only if the running CPU is capable.
> > > > > This kind of miracle can be achieved in two ways:
> > > > >
> > > > > 1/ For generic C code compiled with a recent GCC, a function can
> > > > > be built for several CPUs thanks to the attribute target_clones.
> > > > >
> > > > > 2/ For manually optimized functions using CPU-specific
> > > > > intrinsics or asm, it is possible to build them with non-default
> > > > > flags thanks to the
> > > attribute target.
> > > > >
> > > > > 3/ For manually optimized files using CPU-specific intrinsics or
> > > > > asm, we use specifics flags in the makefile.
> > > > >
> > > > > The function clone in case 1/ is dynamically chosen at run-time
> > > > > through ifunc resolver.
> > > > > The specific functions in cases 2/ and 3/ must chosen at
> > > > > run-time by initializing a function pointer thanks to
> rte_cpu_get_flag_enabled().
> > > > >
> > > > > Note that rte_hash and software crypto PMDs have a run-time
> > > > > check with
> > > > > rte_cpu_get_flag_enabled() but do not override CFLAGS in the
> Makefile.
> > > > > Next step for these libraries?
> > > > >
> > > > > Back to rte_memset, I think you should try the solution 2/.
> > > >
> > > > I have read the ACL code, if I understand well , for complex algo
> > > > implementation, it is good idea, but Choosing functions at run
> > > > time will bring some overhead. For frequently called function
> > > > Which consumes small cycles, the overhead maybe is more than the
> > > > gains
> > > optimizations brings For example, for most applications in dpdk,
> > > memset only set N = 10 or 12bytes. It consumes fewer cycles.
> > >
> > > But then what the point to have an rte_memset() using vector
> > > instructions at all?
> > > From what you are saying the most common case is even less then SSE
> > > register size.
> > > Konstantin
> >
> > For most cases, memset is used such as memset(address, 0,
> > sizeof(struct xxx));
>
> Ok then I suppose for such cases you don't need any special function and
> memset() would still be the best choice, right?
>
In fact, the bad performance drop has been found on IVB, Please reference to
http://dpdk.org/ml/archives/dev/2016-October/048628.html
The following code cause the perf issue
memset((void *)(uintptr_t)&(virtio_hdr->hdr),0 , dev->vhost_hlen);
vhost_hlen is 10 or 12 bytes, So, glibc memset is not used here.
> > The use case here is small by accident, I only give an example here.
> > but rte_memset is introduced to need consider generic case.
>
> We can have rte_memset_huge() or so instead, and document that it should
> be used for sizes greater than some cutoff point.
> Inside it you can just call a function pointer installed at startup (same as
> rte_acl_classify() does).
> For big sizes, I suppose the price of extra function pointer call would not
> affect performance much.
> For sizes smaller then this cutoff point you still can use either
> rte_memset_scalar() or just normal rte_memset().
> Something like that:
>
> extern void *(*__rte_memset_vector)( (void *s, int c, size_t n);
>
> static inline void*
> rte_memset_huge(void *s, int c, size_t n) {
> return __rte_memset_vector(s, c, n);
> }
>
> static inline void *
> rte_memset(void *s, int c, size_t n)
> {
> If (n < XXX)
> return rte_memset_scalar(s, c, n);
> else
> return rte_memset_huge(s, c, n);
> }
>
> XXX could be either a define, or could also be a variable, so it can be setuped
> at startup, depending on the architecture.
>
> Would that work?
> Konstantin
>
The idea sounds good. It maybe is more feasible for rte_memcpy and rte_memset.
If I understand well , the idea from Bruce is similar, right ?
> > sizeof(struct xxx) is not limited to very small size, such as less than SSE
> register size.
> > I just want to say that the size for the most use case is not very
> > large, So cycles consumed Is not large. It is not suited to choose function at
> run-time since overhead is considered.
> >
> > thanks
> > Zhiyong
^ permalink raw reply
* Re: dpdk16.07 and virtio "Cannot mmap IO port resource"
From: Gopakumar Choorakkot Edakkunni @ 2016-12-11 18:52 UTC (permalink / raw)
To: dev, Olivier Matz
In-Reply-To: <CABK1yFAXs6HC9hOy4RF0FLwvOhgeh4EQwp5NRTevwmJOys-qmQ@mail.gmail.com>
nevermind .. I saw the hew ARCH_X86 flag which I dint realise I have to add
in my config file when I moved from dpdk2.0
On Sun, Dec 11, 2016 at 12:29 AM, Gopakumar Choorakkot Edakkunni <
gopakumar.c.e@gmail.com> wrote:
> Somewhere I read that the "offset" parameter for sysfs mmap() needs to be
> the start address of the resource, so I tried the below diff, and mmap
> still fails .. Still scratching my head
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> index 1786b75..e882940 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> @@ -462,8 +462,8 @@ pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
> strerror(errno));
> goto error;
> }
> - addr = mmap(NULL, end_addr + 1, PROT_READ | PROT_WRITE,
> - MAP_SHARED, fd, 0);
> + addr = mmap(NULL, (end_addr-phys_addr) + 1, PROT_READ | PROT_WRITE,
> + MAP_SHARED, fd, phys_addr);
> close(fd);
> if (addr == MAP_FAILED) {
> RTE_LOG(ERR, EAL, "Cannot mmap IO port resource: %s\n",
> @@ -473,7 +473,7 @@ pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
>
> /* strangely, the base address is mmap addr + phys_addr */
> p->base = (uintptr_t)addr + phys_addr;
> - p->len = end_addr + 1;
> + p->len = (end_addr-phys_addr) + 1;
> RTE_LOG(DEBUG, EAL, "PCI Port IO found start=0x%"PRIx64"\n",
> p->base);
> fclose(f);
>
> On Sat, Dec 10, 2016 at 3:21 PM, Gopakumar Choorakkot Edakkunni <
> gopakumar.c.e@gmail.com> wrote:
>
>> Hi Oliver,
>>
>> Looking at the kernel code pci_mmap_resource()--->pci_mmap_fits(), it
>> looks like pci_mmap_fits() expects that the "number of pages" requested to
>> map is no larger than the actual size of the pci resource. But in
>> pci_uio_ioport_map() what is passed as the requested size is the end_addr
>> of the resource, which in my case is 0xc09f, but the size of the resource
>> itself is 0x20 and hence kernel expects one page - but 0xc09f+1
>> (end_addr+1) gets translated to 13 pages ! And I guess that leads to the
>> mmap to fail .. Thoughts on this ?
>>
>> Rgds,
>> Gopa.
>>
>>
>> On Fri, Dec 9, 2016 at 8:30 PM, Gopakumar Choorakkot Edakkunni <
>> gopakumar.c.e@gmail.com> wrote:
>>
>>> I tried to load up dpdk (bound to uio_pci_generic, tried igb_uio also!)
>>> on a virtio interface. Dpdk exits with the "Cannot mmap IO port resource"
>>> complaint - the call chain is legacy_virtio_resource_init()-->pci_uio_ioport_map().
>>>
>>>
>>> If anyone can give any clues/pointers as to what might be wrong, that
>>> can greatly help in getting me on the right track fast !
>>>
>>> ---
>>> EAL: probe driver: 1af4:1000 rte_virtio_pmd
>>> EAL: PCI device 0000:00:05.0 on NUMA socket 0
>>> EAL: probe driver: 1af4:1000 r[ 330.753458] ------------[ cut here
>>> ]------------
>>> rte_virtio_pmd
>>> [ 330.754430] WARNING: CPU: 0 PID: 8063 at drivers/pci/pci-sysfs.c:984
>>> pci_mmap_resource.isra.14+0x113/0x1b0()
>>> [ 330.756083] process "dpdk_master" tried to map 0x0000d000 bytes at
>>> page 0x00000000 on 0000:00:05.0 BAR 0 (start 0x c080, size
>>> 0x 20)
>>> [ 330.758272] Modules linked in: rte_kni igb_uio pppoe ppp_async
>>> iptable_nat cdc_mbim sierra_net rndis_host qmi_wwan qcserial pppox
>>> ppp_generic option nf_nat_pptp nf_nat_ipv4 nf_nat_amanda nf_conntrack_pptp
>>> nf_conntrack_ipv4 nf_conntrack_amanda ipt_MASQUERADE huawei_cdc_ncm
>>> cdc_subset cdc_ncm cdc_ether cdc_eem ax88179_178a asix xt_u32 xt_time
>>> xt_tcpmss xt_string xt_statistic xt_state xt_socket xt_recent xt_quota
>>> xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit
>>> xt_length xt_iprange xt_id xt_hl xt_helper xt_hashlimit xt_esp xt_ecn
>>> xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment
>>> xt_addrtype xt_TPROXY xt_TEE xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_LED
>>> xt_HL xt_DSCP xt_CT xt_CLASSIFY usbnet usb_wwan ts_kmp ts_fsm ts_bm slhc
>>> sierra pl2303 nfnetlink_queue nfnetlink_log nf_nat_tftp nf_nat_snmp_basic
>>> nf_nat_sip nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat
>>> nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip
>>> nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_irc
>>> nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast
>>> lib80211_crypt_wep lib80211_crypt_tkip lib80211_crypt_ccmp lib80211
>>> iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ULOG ipt_REJECT
>>> ipt_ECN hso ftdi_sio crc8 crc7 crc_itu_t crc_ccitt cp210x cordic
>>> compat_xtables cdc_wdm cdc_acm arptable_filter arpt_mangle arp_tables
>>> sch_teql sch_tbf sch_sfq sch_red sch_prio sch_netem sch_htb sch_gred
>>> sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_police
>>> act_ipt act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex
>>> cls_flow cls_route cls_fw sch_hfsc sch_ingress evdev xt_NFQUEUE xt_set
>>> ip_set_list_set ip_set_hash_netport ip_set_hash_netiface ip_set_hash_net
>>> ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport
>>> ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip
>>> ip_set nfnetlink sr_mod cdrom ip6t_REJECT ip6table_raw ip6table_mangle
>>> ip6table_filter ip6_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6
>>> ifb ipip ip6_tunnel tunnel6 tunnel4 ip_tunnel tun mdio loop vfat fat isofs
>>> nls_utf8 nls_iso8859_15 nls_iso8859_1 nls_cp850 nls_cp437 rfkill virtio_rng
>>> sha512_generic sha256_generic sha1_generic md5 arc4 ath10k_pci ath10k_core
>>> ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 compat pcnet32 e1000
>>> virtio_net ohci_hcd ixgbevf ixgbe hwmon igbvf igb dsa_core mii [last
>>> unloaded: igb_uio]
>>> [ 330.805110] CPU: 0 PID: 8063 Comm: dpdk_master Tainted: G W
>>> 3.14.67 #1
>>> [ 330.806104] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>>> BIOS Bochs 01/01/2011
>>> [ 330.806104] 0000000000000286 0000000000000000 ffffffff814e167c
>>> 0000000000000006
>>> [ 330.806104] ffff88008b573cd8 ffffffff81259d73 ffffffff81061b72
>>> ffff88013b24fae0
>>> [ 330.806104] ffff88013b24f800 0000000000000000 ffff88013a498000
>>> ffff88013b24f8a8
>>> [ 330.806104] Call Trace:
>>> [ 330.806104] [<ffffffff814e167c>] ? dump_stack+0x5e/0x7a
>>> [ 330.806104] [<ffffffff81259d73>] ? pci_mmap_resource.isra.14+0x11
>>> 3/0x1b0
>>> [ 330.806104] [<ffffffff81061b72>] ? warn_slowpath_common+0x82/0xb0
>>> [ 330.806104] [<ffffffff81061c55>] ? warn_slowpath_fmt+0x45/0x50
>>> [ 330.806104] [<ffffffff81120321>] ? do_last.isra.58+0xac1/0xc00
>>> [ 330.806104] [<ffffffff81259d73>] ? pci_mmap_resource.isra.14+0x11
>>> 3/0x1b0
>>> [ 330.806104] [<ffffffff8116da79>] ? kernfs_fop_mmap+0x69/0x100
>>> [ 330.806104] [<ffffffff810f4018>] ? mmap_region+0x2e8/0x560
>>> [ 330.806104] [<ffffffff810f45a8>] ? do_mmap_pgoff+0x318/0x3b0
>>> [ 330.806104] [<ffffffff810e1724>] ? vm_mmap_pgoff+0x74/0xc0
>>> [ 330.806104] [<ffffffff810f2d1a>] ? SyS_mmap_pgoff+0x18a/0x1e0
>>> [ 330.806104] [<ffffffff814e7759>] ? system_call_fastpath+0x16/0x1b
>>> [ 330.823897] ---[ end trace c6106b67c768d501 ]---
>>> EAL: Cannot mmap IO port resource: Invalid argument
>>> EAL: Error - exiting with code: 1
>>> Cause: Requested device 0000:00:05.0 cannot be used
>>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH v2 1/5] ethdev: add firmware version get
From: Yang, Qiming @ 2016-12-12 1:28 UTC (permalink / raw)
To: Yigit, Ferruh, dev@dpdk.org; +Cc: Thomas Monjalon, Horton, Remy
In-Reply-To: <4177103b-21af-403c-ad3f-6ab1fac94903@intel.com>
Hi, Yigit
Yes, we had planned to add fw_version in rte_eth_dev_info_get(). But Remy think we should better to implement this feature through a way don't break the original ABI. So I change the implement.
-----Original Message-----
From: Yigit, Ferruh
Sent: Thursday, December 8, 2016 7:07 PM
To: Yang, Qiming <qiming.yang@intel.com>; dev@dpdk.org
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/5] ethdev: add firmware version get
Hi Qiming,
On 12/6/2016 7:16 AM, Qiming Yang wrote:
> This patch adds a new API 'rte_eth_dev_fwver_get' for fetching
> firmware version by a given device.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
<...>
> @@ -1444,6 +1448,7 @@ struct eth_dev_ops {
> /**< Get names of extended statistics. */
> eth_queue_stats_mapping_set_t queue_stats_mapping_set;
> /**< Configure per queue stat counter mapping. */
> + eth_fw_version_get_t fw_version_get; /**< Get firmware version. */
Hi Qiming,
Not sure if I am missing something but this change is for following [1] deprecation notice, right?
If so, notice suggest updating rte_eth_dev_info_get() to include fw_version, but this patch adds a new eth_dev_ops.
Is it agreed to add a new eth_dev_ops for this?
[1]
* In 17.02 ABI change is planned: the ``rte_eth_dev_info`` structure
will be extended with a new member ``fw_version`` in order to store
the NIC firmware version.
> eth_dev_infos_get_t dev_infos_get; /**< Get device info. */
> eth_dev_supported_ptypes_get_t dev_supported_ptypes_get;
> /**< Get packet types supported and identified by device*/
<...>
^ permalink raw reply
* Re: [PATCH v2 0/5] example/ethtool: add bus info and fw version get
From: Yang, Qiming @ 2016-12-12 1:43 UTC (permalink / raw)
To: Horton, Remy, dev@dpdk.org
In-Reply-To: <b556bf81-e70a-9e5a-2db0-f52fe180ac51@intel.com>
Hi, Remy
I'll add this update in v3 patch, thank you for your remind.
BTW, It looks like Yigit don't agree the implement we used, he think we'd better not add a new ops to get this info.
-----Original Message-----
From: Horton, Remy
Sent: Thursday, December 8, 2016 4:34 PM
To: Yang, Qiming <qiming.yang@intel.com>; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 0/5] example/ethtool: add bus info and fw version get
On 06/12/2016 15:16, Qiming Yang wrote:
[..]
> Qiming Yang (5):
> ethdev: add firmware version get
> net/e1000: add firmware version get
> net/ixgbe: add firmware version get
> net/i40e: add firmware version get
> ethtool: dispaly bus info and firmware version
s/dispaly/display
doc/guides/rel_notes/release_17_02.rst ought to be updated as well. Code itself looks ok though..
Acked-by: Remy Horton <remy.horton@intel.com>
^ permalink raw reply
* Does DPDK i40e driver support 'Toeplitz hash'
From: ALeX Wang @ 2016-12-12 6:31 UTC (permalink / raw)
To: dev; +Cc: Keith Amidon
Hi,
We want to use 'Toeplitz hash' for RSS hash on our server equipped with
'Intel X710-DA4' card.
However, seemed that we hit the exact same issue as this:
Why only rx queue "0" can receive network packet by i40e NIC
http://dpdk.org/ml/archives/dev/2015-July/022453.html
...
We are using the v16.11 release and would like to confirm if the issue above
has been address. If so, could anyone post here how to configure?
Appreciate,
Alex Wang,
^ permalink raw reply
* [PATCH v2] vmxnet3: fix Rx deadlock
From: Stefan Puiu @ 2016-12-12 8:21 UTC (permalink / raw)
To: dev; +Cc: yongwang, mac_leehk, Stefan Puiu
In-Reply-To: <1479120376-48723-1-git-send-email-stefan.puiu@gmail.com>
Our use case is that we have an app that needs to keep mbufs around
for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
descriptors (where it returns -err). Since there are no mbufs that the
virtual hardware can use, no packets will be received after this;
nobody retries this later, so the driver gets stuck in this state. I
call this a deadlock for lack of a better term - the virtual HW waits
for free mbufs, while the app waits for the hardware to notify it for
data. Note that after this, the app can't recover.
This fix is a rework of this patch by Marco Lee:
http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port it,
address review comments and also reverted the allocation failure
handing to the first version of the patch
(http://dpdk.org/ml/archives/dev/2015-July/022079.html), since that's
the only approach that seems to work, and seems to be what other
drivers are doing (I checked ixgbe and em). Reusing the mbuf that's
getting passed to the application doesn't seem to make sense, and it
was causing weird issues in our app. Also, reusing rxm without
checking if it's NULL could cause the code to crash.
v2:
- address review comments, reworded description a bit
---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 39 ++++++++++++++++++++++++++++++++++++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index b109168..93db10f 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -518,6 +518,32 @@
return nb_tx;
}
+static inline void
+vmxnet3_renew_desc(vmxnet3_rx_queue_t *rxq, uint8_t ring_id,
+ struct rte_mbuf *mbuf)
+{
+ uint32_t val = 0;
+ struct vmxnet3_cmd_ring *ring = &rxq->cmd_ring[ring_id];
+ struct Vmxnet3_RxDesc *rxd =
+ (struct Vmxnet3_RxDesc *)(ring->base + ring->next2fill);
+ vmxnet3_buf_info_t *buf_info = &ring->buf_info[ring->next2fill];
+
+ if (ring_id == 0)
+ val = VMXNET3_RXD_BTYPE_HEAD;
+ else
+ val = VMXNET3_RXD_BTYPE_BODY;
+
+ buf_info->m = mbuf;
+ buf_info->len = (uint16_t)(mbuf->buf_len - RTE_PKTMBUF_HEADROOM);
+ buf_info->bufPA = rte_mbuf_data_dma_addr_default(mbuf);
+
+ rxd->addr = buf_info->bufPA;
+ rxd->btype = val;
+ rxd->len = buf_info->len;
+ rxd->gen = ring->gen;
+
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+}
/*
* Allocates mbufs and clusters. Post rx descriptors with buffer details
* so that device can receive packets in those buffers.
@@ -657,9 +683,18 @@
}
while (rcd->gen == rxq->comp_ring.gen) {
+ struct rte_mbuf *newm;
+
if (nb_rx >= nb_pkts)
break;
+ newm = rte_mbuf_raw_alloc(rxq->mp);
+ if (unlikely(newm == NULL)) {
+ PMD_RX_LOG(ERR, "Error allocating mbuf");
+ rxq->stats.rx_buf_alloc_failure++;
+ break;
+ }
+
idx = rcd->rxdIdx;
ring_idx = (uint8_t)((rcd->rqID == rxq->qid1) ? 0 : 1);
rxd = (Vmxnet3_RxDesc *)rxq->cmd_ring[ring_idx].base + idx;
@@ -759,8 +794,8 @@
VMXNET3_INC_RING_IDX_ONLY(rxq->cmd_ring[ring_idx].next2comp,
rxq->cmd_ring[ring_idx].size);
- /* It's time to allocate some new buf and renew descriptors */
- vmxnet3_post_rx_bufs(rxq, ring_idx);
+ /* It's time to renew descriptors */
+ vmxnet3_renew_desc(rxq, ring_idx, newm);
if (unlikely(rxq->shared->ctrl.updateRxProd)) {
VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] + (rxq->queue_id * VMXNET3_REG_ALIGN),
rxq->cmd_ring[ring_idx].next2fill);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] vmxnet3: fix Rx deadlock
From: Stefan Puiu @ 2016-12-12 8:27 UTC (permalink / raw)
To: Yong Wang; +Cc: dev@dpdk.org, mac_leehk@yahoo.com.hk
In-Reply-To: <BY2PR05MB2359E5B448AFCF17B7713738AF8C0@BY2PR05MB2359.namprd05.prod.outlook.com>
Hello and thanks for reviewing the patch.
On Wed, Nov 30, 2016 at 6:59 AM, Yong Wang <yongwang@vmware.com> wrote:
[...]
> I think a more accurate description is that the particular descriptor's generation bit never got flipped properly when an mbuf failed to be refilled which caused the rx stuck, rather than vmxnet3_post_rx_bufs() not being called afterwards.
>
Not sure if this kind of level of detail is useful, but if you can
think of a better explanation to put in the changelist, I can add it.
I see the generation bit not flipping as a symptom, while the core
problem is the hardware can't write to the descriptor. I felt the
explanation was going into too much detail anyway, so I've reworded it
a bit for v2. Let me know what you think.
Thanks,
Stefan.
^ permalink raw reply
* Re: [PATCH 3/4] crypto: add sgl support for sw PMDs
From: Kulasek, TomaszX @ 2016-12-12 10:01 UTC (permalink / raw)
To: Michał Mirosław; +Cc: dev@dpdk.org
In-Reply-To: <CAHXqBFKvvV5JjScuoVH=6dE1YUw39RwwwSEQ4sRA=1aGHMQ9QQ@mail.gmail.com>
Hi Michał,
> -----Original Message-----
> From: Michał Mirosław [mailto:mirqus@gmail.com]
> Sent: Saturday, December 3, 2016 09:28
> To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 3/4] crypto: add sgl support for sw PMDs
>
> 2016-12-02 18:07 GMT+01:00 Tomasz Kulasek <tomaszx.kulasek@intel.com>:
> > This patch introduces RTE_CRYPTODEV_FF_MBUF_SCATTER_GATHER feature
> > flag informing that selected crypto device supports segmented mbufs
> > natively and doesn't need to be coalesced before crypto operation.
> >
> > While using segmented buffers in crypto devices may have unpredictable
> > results, for PMDs which doesn't support it natively, additional check
> > is made for debug compilation.
> >
> [...]
> > +#ifdef RTE_LIBRTE_PMD_AESNI_GCM_DEBUG
> > + if (!rte_pktmbuf_is_contiguous(ops[i]->sym->m_src) ||
> > + (ops[i]->sym->m_dst != NULL &&
> > + !rte_pktmbuf_is_contiguous(
> > + ops[i]->sym->m_dst))) {
> > + ops[i]->status =
> RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
> > + GCM_LOG_ERR("PMD supports only contiguous mbufs,
> "
> > + "op (%p) provides noncontiguous mbuf as
> "
> > + "source/destination buffer.\n", ops[i]);
> > + qp->qp_stats.enqueue_err_count++;
> > + break;
> > + }
> > +#endif
> [...]
>
> Why are there so many copies of this code?
>
> Best Regards,
> Michał Mirosław
This is one check per crypto PMD: aesni-gcm, aesni-mb, openssl and so on, enabled per PMD.
Tomasz
^ permalink raw reply
* Re: [PATCH 01/22] ethdev: introduce generic flow API
From: Chandran, Sugesh @ 2016-12-12 10:20 UTC (permalink / raw)
To: Adrien Mazarguil
Cc: Kevin Traynor, dev@dpdk.org, Thomas Monjalon,
De Lara Guarch, Pablo, Olivier Matz
In-Reply-To: <20161209163846.GN10340@6wind.com>
Hi Adrien,
Regards
_Sugesh
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Friday, December 9, 2016 4:39 PM
> To: Chandran, Sugesh <sugesh.chandran@intel.com>
> Cc: Kevin Traynor <ktraynor@redhat.com>; dev@dpdk.org; Thomas
> Monjalon <thomas.monjalon@6wind.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Olivier Matz <olivier.matz@6wind.com>;
> sugesh.chandran@intel.comn
> Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API
>
> Hi Sugesh,
>
> On Fri, Dec 09, 2016 at 12:18:03PM +0000, Chandran, Sugesh wrote:
> [...]
> > > > Are you going to provide any control over the initialization of
> > > > NIC to define the capability matrices For eg; To operate in a L3
> > > > router mode,
> > > software wanted to initialize the NIC port only to consider the L2
> > > and L3 fields.
> > > > I assume the initialization is done based on the first rules that
> > > > are
> > > programmed into the NIC.?
> > >
> > > Precisely, PMDs are supposed to determine the most appropriate
> > > device mode to use in order to handle the requested rules. They may
> > > even switch to another mode if necessary assuming this does not
> > > break existing constraints.
> > >
> > > I think we've discussed an atomic (commit-based) mode of operation
> > > through separate functions as well, where the application would
> > > attempt to create a bunch of rules at once, possibly making it
> > > easier for PMDs to determine the most appropriate mode of operation
> for the device.
> > >
> > > All of these may be added later according to users feedback once the
> > > basic API has settled.
> > [Sugesh] Yes , we discussed about this before. However I feel that, it
> > make sense to provide some flexibility to the user/application to define a
> profile/mode of the device.
> > This way the complexity of determining the mode by itself will be taken
> away from PMD.
> > Looking at the P4 enablement patches in OVS, the mode definition APIs
> > can be used in conjunction
> > P4 behavioral model.
> > For eg: A P4 model for a L2 switch operate OVS as a L2 switch. Using
> > the mode definition APIs Its possible to impose the same behavioral model
> in the hardware too.
> > This way its simple, clean and very predictive though it needs to define an
> additional profile_define APIs.
> > I am sorry to provide the comment at this stage, However looking at
> > the adoption of ebpf, P4 make me to think this way.
> > What do you think?
>
> What you suggest (device profile configuration) would be done by a separate
> function in any case, so as long as everyone agrees on a generic method to
> do so, no problem with extending rte_flow. By default in the meantime we'll
> have to rely on PMDs to make the right decision.
[Sugesh] I am fine with PMD is making the decision on profile/mode selection in
Default case. However we must provide an option for the application to define a mode
and PMD must honor with it to avoid making an invalid mode change.
>
> Do you think it has to be defined from the beginning?
[Sugesh] I feel it's going to be another big topic to decide how proposed mode implementation will be looks like,
What should be available modes and etc. So I am OK to consider as its not part of this flow API definition for now.
However its good to mention that in the API comments section to be aware. Do you agree that?
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply
* Re: [PATCH v3 00/31] net/i40e: base code update
From: Ferruh Yigit @ 2016-12-12 10:32 UTC (permalink / raw)
To: Jingjing Wu, dev; +Cc: helin.zhang
In-Reply-To: <1481369093-102492-1-git-send-email-jingjing.wu@intel.com>
On 12/10/2016 11:24 AM, Jingjing Wu wrote:
> i40e base code upate. The main changes are:
> - add clause22 and clause45 implementation for PHY registers accessing
> - replace existing legacy memcpy() calls with i40e_memcpy() calls.
> - use BIT() macro instead of bit fields
> - add clear all WoL filters implementation
> - add ERROR state for NVM update state machine
> - add broadcast promiscuous control per VLAN
> - remove unused X722_SUPPORT and I40E_NDIS_SUPPORT MARCOs
>
> v3:
> * update commit log of few patches as issue fix
>
> v2:
> * comments rework
> * complie issue fix
> * rebase to dpdk-next-net
>
> Jingjing Wu (31):
> net/i40e/base: add encap csum VF offload flag
> net/i40e/base: fix flow control set for 25G
> net/i40e/base: remove unnecessary code
> net/i40e/base: fix bit test mask
> net/i40e/base: group base mode VF offload flags
> net/i40e/base: fix long link down notification time
> net/i40e/base: add media type detection for 25G link
> net/i40e/base: add clause22 and clause45 implementation
> net/i40e/base: add bus number info
> net/i40e/base: add protocols when discover capabilities
> net/i40e/base: fix unknown PHYs incorrect identification
> net/i40e/base: replace memcpy
> net/i40e/base: deprecating unused macro
> net/i40e/base: remove FPK HyperV VF device ID
> net/i40e/base: add FEC bits to PHY capabilities
> net/i40e/base: use BIT() macro instead of bit fields
> net/i40e/base: adjust 25G PHY type values
> net/i40e/base: implement clear all WoL filters
> net/i40e/base: implement set VSI full promisc mode
> net/i40e/base: fix wol failure on PF reset
> net/i40e/base: save link FEC info from link up event
> net/i40e/base: fix NVM access intefering
> net/i40e/base: change shift values to hex
> net/i40e/base: comment that udp port must be in Host order
> net/i40e/base: remove duplicate definitions
> net/i40e/base: add ERROR state for NVM update state machine
> net/i40e/base: add broadcast promiscuous control per VLAN
> net/i40e/base: fix division by zero
> net/i40e/base: fix byte order
> net/i40e/base: remove unused macro
> net/i40e: remove unused macro from PMD
>
<...>
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply
* Re: [PATCH 02/32] drivers/common: introducing dpaa2 mc driver
From: Hemant Agrawal @ 2016-12-12 10:32 UTC (permalink / raw)
To: Ferruh Yigit, dev
Cc: thomas.monjalon, bruce.richardson, shreyansh.jain,
Cristian Sovaiala
In-Reply-To: <f3ba1542-3868-fea2-d030-bf22766a63fc@intel.com>
On 12/7/2016 1:18 AM, Ferruh Yigit wrote:
> On 12/4/2016 6:16 PM, Hemant Agrawal wrote:
>> This patch intoduces the DPAA2 MC(Management complex Driver)
>>
>> This driver is common to be used by various DPAA2 net, crypto
>> and other drivers
>>
>> Signed-off-by: Cristian Sovaiala <cristian.sovaiala@nxp.com>
>> [Hemant:rebase and conversion to library for DPDK]
>
> Is this note about how work share done? Do we need this in the history?
Yes! We can avoid it.
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> ---
>> config/defconfig_arm64-dpaa2-linuxapp-gcc | 7 +-
>> drivers/Makefile | 1 +
>> drivers/common/Makefile | 36 +++++
>> drivers/common/dpaa2/Makefile | 36 +++++
>> drivers/common/dpaa2/mc/Makefile | 53 ++++++
>> drivers/common/dpaa2/mc/dpaa2_mc_version.map | 4 +
>> drivers/common/dpaa2/mc/fsl_mc_cmd.h | 231 +++++++++++++++++++++++++++
>> drivers/common/dpaa2/mc/fsl_mc_sys.h | 98 ++++++++++++
>> drivers/common/dpaa2/mc/mc_sys.c | 126 +++++++++++++++
>
> Are drivers/common/dpaa2/* files are shared code or implemented for
> DPDK, I can see Linux version is different.
>
> If these are re-implemented for DPDK, let's follow DPDK coding rules for
> a clean start, what do you think?
>
It is not a re-implementation. We do minor changes to make the common
library work in user space with DPDK.
The deviation from kernel is because it is still a work in progress
there. Once it stable there, we will pull in the changes.
>> 9 files changed, 591 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/common/Makefile
>> create mode 100644 drivers/common/dpaa2/Makefile
>> create mode 100644 drivers/common/dpaa2/mc/Makefile
>> create mode 100644 drivers/common/dpaa2/mc/dpaa2_mc_version.map
>> create mode 100644 drivers/common/dpaa2/mc/fsl_mc_cmd.h
>> create mode 100644 drivers/common/dpaa2/mc/fsl_mc_sys.h
>> create mode 100644 drivers/common/dpaa2/mc/mc_sys.c
>>
>> diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc b/config/defconfig_arm64-dpaa2-linuxapp-gcc
>> index 66df54c..00f207e 100644
>> --- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
>> +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
>> @@ -1,6 +1,7 @@
>> # BSD LICENSE
>> #
>> -# Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
>> +# Copyright (c) 2016 Freescale Semiconductor, Inc. All rights reserved.
>> +# Copyright (c) 2016 NXP. All rights reserved.
>> #
>> # Redistribution and use in source and binary forms, with or without
>> # modification, are permitted provided that the following conditions
>> @@ -40,3 +41,7 @@ CONFIG_RTE_ARCH_ARM_TUNE="cortex-a57+fp+simd"
>> #
>> CONFIG_RTE_MAX_LCORE=8
>> CONFIG_RTE_MAX_NUMA_NODES=1
>> +
>> +# Compile software PMD backed by NXP DPAA2 files
>> +#
>> +CONFIG_RTE_LIBRTE_DPAA2_PMD=y
>
> Currently how it works is, default value of the config in "common_base"
> and it is overwritten in specific config files.
> So this config option also should go to "common_base" as disabled by
> default.
>
> And the other config option too, mentioned in the documentation.
>
OK
>> diff --git a/drivers/Makefile b/drivers/Makefile
>> index 81c03a8..d5580f6 100644
>> --- a/drivers/Makefile
>> +++ b/drivers/Makefile
>> @@ -31,6 +31,7 @@
>>
>> include $(RTE_SDK)/mk/rte.vars.mk
>>
>> +DIRS-y += common
>> DIRS-y += net
>> DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto
>>
>> diff --git a/drivers/common/Makefile b/drivers/common/Makefile
>> new file mode 100644
>> index 0000000..0c3f35f
>> --- /dev/null
>> +++ b/drivers/common/Makefile
>> @@ -0,0 +1,36 @@
>> +# BSD LICENSE
>> +#
>> +# Copyright(c) 2016 NXP. 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 NXP 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
>> +
>> +DIRS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += dpaa2
>> +
>> +include $(RTE_SDK)/mk/rte.subdir.mk
>> diff --git a/drivers/common/dpaa2/Makefile b/drivers/common/dpaa2/Makefile
>> new file mode 100644
>> index 0000000..a4f80c1
>> --- /dev/null
>> +++ b/drivers/common/dpaa2/Makefile
>> @@ -0,0 +1,36 @@
>> +# BSD LICENSE
>> +#
>> +# Copyright(c) 2016 NXP. 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 NXP 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
>> +
>> +DIRS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += mc
>> +
>> +include $(RTE_SDK)/mk/rte.subdir.mk
>> diff --git a/drivers/common/dpaa2/mc/Makefile b/drivers/common/dpaa2/mc/Makefile
>> new file mode 100644
>> index 0000000..9632168
>> --- /dev/null
>> +++ b/drivers/common/dpaa2/mc/Makefile
>> @@ -0,0 +1,53 @@
>> +# BSD LICENSE
>> +#
>> +# Copyright(c) 2016 NXP. 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 NXP 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
>> +RTE_SDK_MC=$(RTE_SDK)/drivers/common/dpaa2
>> +
>> +#
>> +# library name
>> +#
>> +LIB = libdpaa2_mc.a
>
> Not sure about this name, what do you think sticking the name used for
> pmd, like: librte_pmd_dpaa2_mc.a ?
We can do it. however dpaa2_mc is not a pmd in itself. It is library for
dpaa2 PMDs (net and crypto).
We did this to distinguish from a regular PMD. Do you suggest something
else?
>> +
>> +CFLAGS += -O3
>> +CFLAGS += $(WERROR_FLAGS)
>> +CFLAGS +=-Wno-strict-aliasing
>> +
>> +CFLAGS += -I$(RTE_SDK_MC)/mc
>> +EXPORT_MAP := dpaa2_mc_version.map
>
> Same comment for version file naming, rte_pmd_dpaa2_mc_version.map ?
>
>> +
>> +LIBABIVER := 1
>> +
>> +SRCS-y += \
>> + mc_sys.c
>
> Also this is fine, since this folder included only if
> CONFIG_RTE_LIBRTE_DPAA2_PMD=y, to be consistent for rest of the Makefiles:
> SRCS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += mc_sys.c
>
OK
>> +
>> +
>> +include $(RTE_SDK)/mk/rte.lib.mk
>> diff --git a/drivers/common/dpaa2/mc/dpaa2_mc_version.map b/drivers/common/dpaa2/mc/dpaa2_mc_version.map
>> new file mode 100644
>> index 0000000..31eca32
>> --- /dev/null
>> +++ b/drivers/common/dpaa2/mc/dpaa2_mc_version.map
>> @@ -0,0 +1,4 @@
>> +DPDK_17.02 {
>> +
>> + local: *;
>> +};
>> diff --git a/drivers/common/dpaa2/mc/fsl_mc_cmd.h b/drivers/common/dpaa2/mc/fsl_mc_cmd.h
>> new file mode 100644
>> index 0000000..cbd3995
>> --- /dev/null
>> +++ b/drivers/common/dpaa2/mc/fsl_mc_cmd.h
>> @@ -0,0 +1,231 @@
>> +/* Copyright 2013-2016 Freescale Semiconductor Inc.
>> + * Copyright (c) 2016 NXP.
>> + *
>> + * 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 the above-listed copyright holders nor the
>> + * names of any contributors may be used to endorse or promote products
>> + * derived from this software without specific prior written permission.
>> + *
>> + *
>> + * ALTERNATIVELY, this software may be distributed under the terms of the
>> + * GNU General Public License ("GPL") as published by the Free Software
>> + * Foundation, either version 2 of that License or (at your option) any
>> + * later version.
>> + *
>> + * 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 HOLDERS 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.
>> + */
>> +#ifndef __FSL_MC_CMD_H
>> +#define __FSL_MC_CMD_H
>> +
>> +#define MC_CMD_NUM_OF_PARAMS 7
>> +
>> +#define MAKE_UMASK64(_width) \
>> + ((uint64_t)((_width) < 64 ? ((uint64_t)1 << (_width)) - 1 : \
>> + (uint64_t)-1))
>> +
>> +static inline uint64_t mc_enc(int lsoffset, int width, uint64_t val)
>> +{
>> + return (uint64_t)(((uint64_t)val & MAKE_UMASK64(width)) << lsoffset);
>> +}
>> +
>> +static inline uint64_t mc_dec(uint64_t val, int lsoffset, int width)
>> +{
>> + return (uint64_t)((val >> lsoffset) & MAKE_UMASK64(width));
>> +}
>> +
>> +struct mc_command {
>> + uint64_t header;
>> + uint64_t params[MC_CMD_NUM_OF_PARAMS];
>> +};
>> +
>> +/**
>> + * enum mc_cmd_status - indicates MC status at command response
>> + * @MC_CMD_STATUS_OK: Completed successfully
>> + * @MC_CMD_STATUS_READY: Ready to be processed
>> + * @MC_CMD_STATUS_AUTH_ERR: Authentication error
>> + * @MC_CMD_STATUS_NO_PRIVILEGE: No privilege
>> + * @MC_CMD_STATUS_DMA_ERR: DMA or I/O error
>> + * @MC_CMD_STATUS_CONFIG_ERR: Configuration error
>> + * @MC_CMD_STATUS_TIMEOUT: Operation timed out
>> + * @MC_CMD_STATUS_NO_RESOURCE: No resources
>> + * @MC_CMD_STATUS_NO_MEMORY: No memory available
>> + * @MC_CMD_STATUS_BUSY: Device is busy
>> + * @MC_CMD_STATUS_UNSUPPORTED_OP: Unsupported operation
>> + * @MC_CMD_STATUS_INVALID_STATE: Invalid state
>> + */
>> +enum mc_cmd_status {
>> + MC_CMD_STATUS_OK = 0x0,
>> + MC_CMD_STATUS_READY = 0x1,
>> + MC_CMD_STATUS_AUTH_ERR = 0x3,
>> + MC_CMD_STATUS_NO_PRIVILEGE = 0x4,
>> + MC_CMD_STATUS_DMA_ERR = 0x5,
>> + MC_CMD_STATUS_CONFIG_ERR = 0x6,
>> + MC_CMD_STATUS_TIMEOUT = 0x7,
>> + MC_CMD_STATUS_NO_RESOURCE = 0x8,
>> + MC_CMD_STATUS_NO_MEMORY = 0x9,
>> + MC_CMD_STATUS_BUSY = 0xA,
>> + MC_CMD_STATUS_UNSUPPORTED_OP = 0xB,
>> + MC_CMD_STATUS_INVALID_STATE = 0xC
>> +};
>> +
>> +/* MC command flags */
>> +
>> +/**
>> + * High priority flag
>> + */
>> +#define MC_CMD_FLAG_PRI 0x00008000
>> +/**
>> + * Command completion flag
>> + */
>> +#define MC_CMD_FLAG_INTR_DIS 0x01000000
>> +
>> +/**
>> + * Command ID field offset
>> + */
>> +#define MC_CMD_HDR_CMDID_O 48
>> +/**
>> + * Command ID field size
>> + */
>> +#define MC_CMD_HDR_CMDID_S 16
>> +/**
>> + * Token field offset
>> + */
>> +#define MC_CMD_HDR_TOKEN_O 32
>> +/**
>> + * Token field size
>> + */
>> +#define MC_CMD_HDR_TOKEN_S 16
>> +/**
>> + * Status field offset
>> + */
>> +#define MC_CMD_HDR_STATUS_O 16
>> +/**
>> + * Status field size
>> + */
>> +#define MC_CMD_HDR_STATUS_S 8
>> +/**
>> + * Flags field offset
>> + */
>> +#define MC_CMD_HDR_FLAGS_O 0
>> +/**
>> + * Flags field size
>> + */
>> +#define MC_CMD_HDR_FLAGS_S 32
>> +/**
>> + * Command flags mask
>> + */
>> +#define MC_CMD_HDR_FLAGS_MASK 0xFF00FF00
>> +
>> +#define MC_CMD_HDR_READ_STATUS(_hdr) \
>> + ((enum mc_cmd_status)mc_dec((_hdr), \
>> + MC_CMD_HDR_STATUS_O, MC_CMD_HDR_STATUS_S))
>> +
>> +#define MC_CMD_HDR_READ_TOKEN(_hdr) \
>> + ((uint16_t)mc_dec((_hdr), MC_CMD_HDR_TOKEN_O, MC_CMD_HDR_TOKEN_S))
>> +
>> +#define MC_PREP_OP(_ext, _param, _offset, _width, _type, _arg) \
>> + ((_ext)[_param] |= cpu_to_le64(mc_enc((_offset), (_width), _arg)))
>> +
>> +#define MC_EXT_OP(_ext, _param, _offset, _width, _type, _arg) \
>> + (_arg = (_type)mc_dec(cpu_to_le64(_ext[_param]), (_offset), (_width)))
>> +
>> +#define MC_CMD_OP(_cmd, _param, _offset, _width, _type, _arg) \
>> + ((_cmd).params[_param] |= mc_enc((_offset), (_width), _arg))
>> +
>> +#define MC_RSP_OP(_cmd, _param, _offset, _width, _type, _arg) \
>> + (_arg = (_type)mc_dec(_cmd.params[_param], (_offset), (_width)))
>> +
>> +/* cmd, param, offset, width, type, arg_name */
>> +#define CMD_CREATE_RSP_GET_OBJ_ID_PARAM0(cmd, object_id) \
>> + MC_RSP_OP(cmd, 0, 0, 32, uint32_t, object_id)
>> +
>> +/* cmd, param, offset, width, type, arg_name */
>> +#define CMD_DESTROY_SET_OBJ_ID_PARAM0(cmd, object_id) \
>> + MC_CMD_OP(cmd, 0, 0, 32, uint32_t, object_id)
>> +
>> +static inline uint64_t mc_encode_cmd_header(uint16_t cmd_id,
>> + uint32_t cmd_flags,
>> + uint16_t token)
>> +{
>> + uint64_t hdr;
>> +
>> + hdr = mc_enc(MC_CMD_HDR_CMDID_O, MC_CMD_HDR_CMDID_S, cmd_id);
>> + hdr |= mc_enc(MC_CMD_HDR_FLAGS_O, MC_CMD_HDR_FLAGS_S,
>> + (cmd_flags & MC_CMD_HDR_FLAGS_MASK));
>> + hdr |= mc_enc(MC_CMD_HDR_TOKEN_O, MC_CMD_HDR_TOKEN_S, token);
>> + hdr |= mc_enc(MC_CMD_HDR_STATUS_O, MC_CMD_HDR_STATUS_S,
>> + MC_CMD_STATUS_READY);
>> +
>> + return hdr;
>> +}
>> +
>> +/**
>> + * mc_write_command - writes a command to a Management Complex (MC) portal
>> + *
>> + * @portal: pointer to an MC portal
>> + * @cmd: pointer to a filled command
>> + */
>> +static inline void mc_write_command(struct mc_command __iomem *portal,
>> + struct mc_command *cmd)
>> +{
>> + int i;
>> + uint32_t word;
>> +
>> + /* copy command parameters into the portal */
>> + for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>> + iowrite64(cmd->params[i], &portal->params[i]);
>> +
>> + /* submit the command by writing the header */
>> + word = (uint32_t)mc_dec(cmd->header, 32, 32);
>> + iowrite32(word, (((uint32_t *)&portal->header) + 1));
>> +
>> + word = (uint32_t)mc_dec(cmd->header, 0, 32);
>> + iowrite32(word, (uint32_t *)&portal->header);
>> +}
>> +
>> +/**
>> + * mc_read_response - reads the response for the last MC command from a
>> + * Management Complex (MC) portal
>> + *
>> + * @portal: pointer to an MC portal
>> + * @resp: pointer to command response buffer
>> + *
>> + * Returns MC_CMD_STATUS_OK on Success; Error code otherwise.
>> + */
>> +static inline enum mc_cmd_status mc_read_response(
>> + struct mc_command __iomem *portal,
>> + struct mc_command *resp)
>> +{
>> + int i;
>> + enum mc_cmd_status status;
>> +
>> + /* Copy command response header from MC portal: */
>> + resp->header = ioread64(&portal->header);
>> + status = MC_CMD_HDR_READ_STATUS(resp->header);
>> + if (status != MC_CMD_STATUS_OK)
>> + return status;
>> +
>> + /* Copy command response data from MC portal: */
>> + for (i = 0; i < MC_CMD_NUM_OF_PARAMS; i++)
>> + resp->params[i] = ioread64(&portal->params[i]);
>> +
>> + return status;
>> +}
>> +
>> +#endif /* __FSL_MC_CMD_H */
>> diff --git a/drivers/common/dpaa2/mc/fsl_mc_sys.h b/drivers/common/dpaa2/mc/fsl_mc_sys.h
>> new file mode 100644
>> index 0000000..d9d43e5
>> --- /dev/null
>> +++ b/drivers/common/dpaa2/mc/fsl_mc_sys.h
>> @@ -0,0 +1,98 @@
>> +/* Copyright 2013-2015 Freescale Semiconductor Inc.
>> + *
>> + * 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 the above-listed copyright holders nor the
>> + * names of any contributors may be used to endorse or promote products
>> + * derived from this software without specific prior written permission.
>> + *
>> + *
>> + * ALTERNATIVELY, this software may be distributed under the terms of the
>> + * GNU General Public License ("GPL") as published by the Free Software
>> + * Foundation, either version 2 of that License or (at your option) any
>> + * later version.
>> + *
>> + * 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 HOLDERS 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.
>> + */
>> +#ifndef _FSL_MC_SYS_H
>> +#define _FSL_MC_SYS_H
>> +
>> +#ifdef __linux_driver__
>> +
>> +#include <linux/errno.h>
>> +#include <asm/io.h>
>> +#include <linux/slab.h>
>> +
>> +struct fsl_mc_io {
>> + void *regs;
>> +};
>> +
>> +#ifndef ENOTSUP
>> +#define ENOTSUP 95
>> +#endif
>> +
>> +#define ioread64(_p) readq(_p)
>> +#define iowrite64(_v, _p) writeq(_v, _p)
>> +
>> +#else /* __linux_driver__ */
>> +
>> +#include <stdio.h>
>> +#include <libio.h>
>> +#include <stdint.h>
>> +#include <errno.h>
>> +#include <sys/uio.h>
>> +#include <linux/byteorder/little_endian.h>
>> +
>> +#define cpu_to_le64(x) __cpu_to_le64(x)
>> +#ifndef dmb
>> +#define dmb() {__asm__ __volatile__("" : : : "memory"); }
>> +#endif
>> +#define __iormb() dmb()
>> +#define __iowmb() dmb()
>> +#define __arch_getq(a) (*(volatile unsigned long *)(a))
>> +#define __arch_putq(v, a) (*(volatile unsigned long *)(a) = (v))
>> +#define __arch_putq32(v, a) (*(volatile unsigned int *)(a) = (v))
>> +#define readq(c) \
>> + ({ uint64_t __v = __arch_getq(c); __iormb(); __v; })
>> +#define writeq(v, c) \
>> + ({ uint64_t __v = v; __iowmb(); __arch_putq(__v, c); __v; })
>> +#define writeq32(v, c) \
>> + ({ uint32_t __v = v; __iowmb(); __arch_putq32(__v, c); __v; })
>> +#define ioread64(_p) readq(_p)
>> +#define iowrite64(_v, _p) writeq(_v, _p)
>> +#define iowrite32(_v, _p) writeq32(_v, _p)
>> +#define __iomem
>> +
>> +struct fsl_mc_io {
>> + void *regs;
>> +};
>> +
>> +#ifndef ENOTSUP
>> +#define ENOTSUP 95
>> +#endif
>> +
>> +/*GPP is supposed to use MC commands with low priority*/
>> +#define CMD_PRI_LOW 0 /*!< Low Priority command indication */
>> +
>> +struct mc_command;
>> +
>> +int mc_send_command(struct fsl_mc_io *mc_io, struct mc_command *cmd);
>> +
>> +#endif /* __linux_driver__ */
>> +
>> +#endif /* _FSL_MC_SYS_H */
>> diff --git a/drivers/common/dpaa2/mc/mc_sys.c b/drivers/common/dpaa2/mc/mc_sys.c
>> new file mode 100644
>> index 0000000..e12a18b
>> --- /dev/null
>> +++ b/drivers/common/dpaa2/mc/mc_sys.c
>> @@ -0,0 +1,126 @@
>> +/* Copyright 2013-2015 Freescale Semiconductor Inc.
>> + *
>> + * 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 the above-listed copyright holders nor the
>> + * names of any contributors may be used to endorse or promote products
>> + * derived from this software without specific prior written permission.
>> + *
>> + *
>> + * ALTERNATIVELY, this software may be distributed under the terms of the
>> + * GNU General Public License ("GPL") as published by the Free Software
>> + * Foundation, either version 2 of that License or (at your option) any
>> + * later version.
>> + *
>> + * 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 HOLDERS 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 <fsl_mc_sys.h>
>> +#include <fsl_mc_cmd.h>
>> +
>> +/** User space framework uses MC Portal in shared mode. Following change
>> +* introduces lock in MC FLIB
>> +*/
>> +
>> +/**
>> +* The mc_spinlock_t type.
>> +*/
>> +typedef struct {
>> + volatile int locked; /**< lock status 0 = unlocked, 1 = locked */
>> +} mc_spinlock_t;
>> +
>> +/**
>> +* A static spinlock initializer.
>> +*/
>> +static mc_spinlock_t mc_portal_lock = { 0 };
>> +
>> +static inline void mc_pause(void) {}
>> +
>> +static inline void mc_spinlock_lock(mc_spinlock_t *sl)
>> +{
>> + while (__sync_lock_test_and_set(&sl->locked, 1))
>> + while (sl->locked)
>> + mc_pause();
>> +}
>> +
>> +static inline void mc_spinlock_unlock(mc_spinlock_t *sl)
>> +{
>> + __sync_lock_release(&sl->locked);
>> +}
>> +
>> +static int mc_status_to_error(enum mc_cmd_status status)
>> +{
>> + switch (status) {
>> + case MC_CMD_STATUS_OK:
>> + return 0;
>> + case MC_CMD_STATUS_AUTH_ERR:
>> + return -EACCES; /* Token error */
>> + case MC_CMD_STATUS_NO_PRIVILEGE:
>> + return -EPERM; /* Permission denied */
>> + case MC_CMD_STATUS_DMA_ERR:
>> + return -EIO; /* Input/Output error */
>> + case MC_CMD_STATUS_CONFIG_ERR:
>> + return -EINVAL; /* Device not configured */
>> + case MC_CMD_STATUS_TIMEOUT:
>> + return -ETIMEDOUT; /* Operation timed out */
>> + case MC_CMD_STATUS_NO_RESOURCE:
>> + return -ENAVAIL; /* Resource temporarily unavailable */
>> + case MC_CMD_STATUS_NO_MEMORY:
>> + return -ENOMEM; /* Cannot allocate memory */
>> + case MC_CMD_STATUS_BUSY:
>> + return -EBUSY; /* Device busy */
>> + case MC_CMD_STATUS_UNSUPPORTED_OP:
>> + return -ENOTSUP; /* Operation not supported by device */
>> + case MC_CMD_STATUS_INVALID_STATE:
>> + return -ENODEV; /* Invalid device state */
>> + default:
>> + break;
>> + }
>> +
>> + /* Not expected to reach here */
>> + return -EINVAL;
>> +}
>> +
>> +int mc_send_command(struct fsl_mc_io *mc_io, struct mc_command *cmd)
>> +{
>> + enum mc_cmd_status status;
>> +
>> + if (!mc_io || !mc_io->regs)
>> + return -EACCES;
>> +
>> + /* --- Call lock function here in case portal is shared --- */
>> + mc_spinlock_lock(&mc_portal_lock);
>> +
>> + mc_write_command(mc_io->regs, cmd);
>> +
>> + /* Spin until status changes */
>> + do {
>> + status = MC_CMD_HDR_READ_STATUS(ioread64(mc_io->regs));
>> +
>> + /* --- Call wait function here to prevent blocking ---
>> + * Change the loop condition accordingly to exit on timeout.
>> + */
>> + } while (status == MC_CMD_STATUS_READY);
>> +
>> + /* Read the response back into the command buffer */
>> + mc_read_response(mc_io->regs, cmd);
>> +
>> + /* --- Call unlock function here in case portal is shared --- */
>> + mc_spinlock_unlock(&mc_portal_lock);
>> +
>> + return mc_status_to_error(status);
>> +}
>>
>
>
^ permalink raw reply
* Re: [PATCH 01/22] ethdev: introduce generic flow API
From: Adrien Mazarguil @ 2016-12-12 11:17 UTC (permalink / raw)
To: Chandran, Sugesh
Cc: Kevin Traynor, dev@dpdk.org, Thomas Monjalon,
De Lara Guarch, Pablo, Olivier Matz
In-Reply-To: <2EF2F5C0CC56984AA024D0B180335FCB13EC4F76@IRSMSX102.ger.corp.intel.com>
Hi Sugesh,
On Mon, Dec 12, 2016 at 10:20:18AM +0000, Chandran, Sugesh wrote:
> Hi Adrien,
>
> Regards
> _Sugesh
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Friday, December 9, 2016 4:39 PM
> > To: Chandran, Sugesh <sugesh.chandran@intel.com>
> > Cc: Kevin Traynor <ktraynor@redhat.com>; dev@dpdk.org; Thomas
> > Monjalon <thomas.monjalon@6wind.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; Olivier Matz <olivier.matz@6wind.com>;
> > sugesh.chandran@intel.comn
> > Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API
> >
> > Hi Sugesh,
> >
> > On Fri, Dec 09, 2016 at 12:18:03PM +0000, Chandran, Sugesh wrote:
> > [...]
> > > > > Are you going to provide any control over the initialization of
> > > > > NIC to define the capability matrices For eg; To operate in a L3
> > > > > router mode,
> > > > software wanted to initialize the NIC port only to consider the L2
> > > > and L3 fields.
> > > > > I assume the initialization is done based on the first rules that
> > > > > are
> > > > programmed into the NIC.?
> > > >
> > > > Precisely, PMDs are supposed to determine the most appropriate
> > > > device mode to use in order to handle the requested rules. They may
> > > > even switch to another mode if necessary assuming this does not
> > > > break existing constraints.
> > > >
> > > > I think we've discussed an atomic (commit-based) mode of operation
> > > > through separate functions as well, where the application would
> > > > attempt to create a bunch of rules at once, possibly making it
> > > > easier for PMDs to determine the most appropriate mode of operation
> > for the device.
> > > >
> > > > All of these may be added later according to users feedback once the
> > > > basic API has settled.
> > > [Sugesh] Yes , we discussed about this before. However I feel that, it
> > > make sense to provide some flexibility to the user/application to define a
> > profile/mode of the device.
> > > This way the complexity of determining the mode by itself will be taken
> > away from PMD.
> > > Looking at the P4 enablement patches in OVS, the mode definition APIs
> > > can be used in conjunction
> > > P4 behavioral model.
> > > For eg: A P4 model for a L2 switch operate OVS as a L2 switch. Using
> > > the mode definition APIs Its possible to impose the same behavioral model
> > in the hardware too.
> > > This way its simple, clean and very predictive though it needs to define an
> > additional profile_define APIs.
> > > I am sorry to provide the comment at this stage, However looking at
> > > the adoption of ebpf, P4 make me to think this way.
> > > What do you think?
> >
> > What you suggest (device profile configuration) would be done by a separate
> > function in any case, so as long as everyone agrees on a generic method to
> > do so, no problem with extending rte_flow. By default in the meantime we'll
> > have to rely on PMDs to make the right decision.
> [Sugesh] I am fine with PMD is making the decision on profile/mode selection in
> Default case. However we must provide an option for the application to define a mode
> and PMD must honor with it to avoid making an invalid mode change.
> >
> > Do you think it has to be defined from the beginning?
> [Sugesh] I feel it's going to be another big topic to decide how proposed mode implementation will be looks like,
> What should be available modes and etc. So I am OK to consider as its not part of this flow API definition for now.
> However its good to mention that in the API comments section to be aware. Do you agree that?
Will do, I'll mention it in the "future evolutions" section.
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH v12 1/6] ethdev: add Tx preparation
From: Ananyev, Konstantin @ 2016-12-12 11:51 UTC (permalink / raw)
To: Kulasek, TomaszX, Olivier Matz; +Cc: Thomas Monjalon, dev@dpdk.org
In-Reply-To: <3042915272161B4EB253DA4D77EB373A14F5A409@IRSMSX102.ger.corp.intel.com>
Hi Olivier and Tomasz,
> -----Original Message-----
> From: Kulasek, TomaszX
> Sent: Friday, December 9, 2016 5:19 PM
> To: Olivier Matz <olivier.matz@6wind.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation
>
> Hi Oliver,
>
> My 5 cents below:
>
> > -----Original Message-----
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Thursday, December 8, 2016 18:24
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Kulasek, TomaszX
> > <tomaszx.kulasek@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation
> >
> > Hi Konstantin,
> >
> > On Fri, 2 Dec 2016 16:17:51 +0000, "Ananyev, Konstantin"
> > <konstantin.ananyev@intel.com> wrote:
> > > Hi Olivier,
> > >
> > > > -----Original Message-----
> > > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > > Sent: Friday, December 2, 2016 8:24 AM
> > > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > > Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Kulasek, TomaszX
> > > > <tomaszx.kulasek@intel.com>; dev@dpdk.org Subject: Re: [dpdk-dev]
> > > > [PATCH v12 1/6] ethdev: add Tx preparation
> > > >
> > > > Hi Konstantin,
> > > >
> > > > On Fri, 2 Dec 2016 01:06:30 +0000, "Ananyev, Konstantin"
> > > > <konstantin.ananyev@intel.com> wrote:
> > > > > >
> > > > > > 2016-11-23 18:36, Tomasz Kulasek:
> > > > > > > +/**
> > > > > > > + * Process a burst of output packets on a transmit queue of
> > > > > > > an Ethernet device.
> > > > > > > + *
> > > > > > > + * The rte_eth_tx_prepare() function is invoked to prepare
> > > > > > > output packets to be
> > > > > > > + * transmitted on the output queue *queue_id* of the Ethernet
> > > > > > > device designated
> > > > > > > + * by its *port_id*.
> > > > > > > + * The *nb_pkts* parameter is the number of packets to be
> > > > > > > prepared which are
> > > > > > > + * supplied in the *tx_pkts* array of *rte_mbuf* structures,
> > > > > > > each of them
> > > > > > > + * allocated from a pool created with
> > > > > > > rte_pktmbuf_pool_create().
> > > > > > > + * For each packet to send, the rte_eth_tx_prepare() function
> > > > > > > performs
> > > > > > > + * the following operations:
> > > > > > > + *
> > > > > > > + * - Check if packet meets devices requirements for tx
> > > > > > > offloads.
> > > > > > > + *
> > > > > > > + * - Check limitations about number of segments.
> > > > > > > + *
> > > > > > > + * - Check additional requirements when debug is enabled.
> > > > > > > + *
> > > > > > > + * - Update and/or reset required checksums when tx offload
> > > > > > > is set for packet.
> > > > > > > + *
> > > > > > > + * Since this function can modify packet data, provided mbufs
> > > > > > > must be safely
> > > > > > > + * writable (e.g. modified data cannot be in shared
> > > > > > > segment).
> > > > > >
> > > > > > I think we will have to remove this limitation in next releases.
> > > > > > As we don't know how it could affect the API, I suggest to
> > > > > > declare this API EXPERIMENTAL.
> > > > >
> > > > > While I don't really mind to mart it as experimental, I don't
> > > > > really understand the reasoning: Why " this function can modify
> > > > > packet data, provided mbufs must be safely writable" suddenly
> > > > > becomes a problem? That seems like and obvious limitation to me
> > > > > and let say tx_burst() has the same one. Second, I don't see how
> > > > > you are going to remove it without introducing a heavy performance
> > > > > impact. Konstantin
> > > >
> > > > About tx_burst(), I don't think we should force the user to provide
> > > > a writable mbuf. There are many use cases where passing a clone
> > > > already works as of today and it avoids duplicating the mbuf data.
> > > > For instance: traffic generator, multicast, bridging/tap, etc...
> > > >
> > > > Moreover, this requirement would be inconsistent with the model you
> > > > are proposing in case of pipeline:
> > > > - tx_prepare() on core X, may update the data
> > > > - tx_burst() on core Y, should not touch the data to avoid cache
> > > > misses
> > >
> > > Probably I wasn't very clear in my previous mail.
> > > I am not saying that we should force the user to pass a writable mbuf.
> > > What I am saying that for tx_burst() current expectation is that after
> > > mbuf is handled to tx_burst() user shouldn't try to modify its buffer
> > > contents till TX engine is done with the buffer (mbuf_free() is called
> > > by TX func for it). For tx_prep(), I think, it is the same though
> > > restrictions are a bit more strict: user should not try to read/write
> > > to the mbuf while tx_prep() is not finished with it. What puzzles me
> > > is that why that should be the reason to mark tx_prep() as
> > > experimental. Konstantin
> >
> > To be sure we're on the same page, let me reword:
> >
> > - mbufs passed to tx_prepare() by the application must have their
> > headers (l2_len + l3_len + l4_len) writable because the phdr checksum
> > can be replaced. It could be precised in the api comment.
> >
> > - mbufs passed to tx_burst() must not be modified by the driver/hw, nor
> > by the application.
Yes, agree with both.
> >
> >
> > About the API itself, I have one more question. I know you've already
> > discussed this a bit with Adrien, I don't want to spawn a new big thread
> > from here ;)
> >
> > The API provides tx_prepare() to check the packets have the proper format,
> > and possibly modify them (ex: csum offload / tso) to match hw
> > requirements. So it does both checks (number of segments) and fixes
> > (csum/tso). What determines things that should be checked and things that
> > should be fixed?
> >
Just to echo Tomasz detailed reply below: I think right now tx_prepare()
doesn't make any fixing.
It just: checks that packet satisfies PMD/HW requirements, if not returns
an error without trying to fix anything/
If the packet seems valid - calculates and fills L4 cksum to fulfill HW reqs .
About the question what should be checked - as usual there is a tradeoff between
additional checks and performance.
As Tomasz stated below right now in non-debug mode we do checks only for things
that can have a critical impact on HW itself (tx hang, etc.).
All extra checks are implemented only in DEBUG mode right now.
>
> 1) Performance -- we may assume that packets are created with the common rules (e.g. doesn't tries to count IP checksum for IPv6
> packet, sets all required fields, etc.). For now, additional checks are done only in DEBUG mode.
>
> 2) Uncommon requirements, such a number of segments for TSO/non-TSO, where invalid values can cause unexpected results (or
> even hang device on burst), so it is critical (at least for ixgbe and i40e) and must be checked.
>
> 3) Checksum field must be initialized in a hardware specific way to count it properly.
>
> 4) If packet is invalid its content isn't modified nor restored.
>
> > The application gets few information from tx_prepare() about what should
> > be done to make the packet accepted by the hw, and the actions will
> > probably be different depending on hardware.
That's true.
I am open to suggestions how in future to provide extra information to the upper layer.
Set rte_errno to different values depending on type of error,
OR extra parameter in tx_prepare() that will provide more detailed error information,
OR something else?
> So could we imagine that in
> > the future the function also tries to fix the packet? I've seen your
> > comment saying that it has to be an application decision, so what about
> > having a parameter saying "fix the packet" or "don't fix it"?
> >
While I am not directly opposed to that idea, I am a bit skeptical
that it could be implemented in useful and effective way.
As I said before it may be fixed in different ways:
coalesce mbufs, split mbuf chain into multiple ones,
might be some sort of combination of these 2 approaches.
Again it seems a bit ineffective from performance point of view:
form packet first then check and re-adjust it again.
Seems more plausible to have it formed in a right way straightway.
Also it would mean that we'll need to pass to tx_prepare() information
about which mempool to use for new mbufs, probably some extra information.
That's why I think it might be better to do a proper (re)formatting of the packet
before passing it down to tx_prepare().
Might be some sort of generic helper function in rte_net that would use information
from rte_eth_desc_lim and could be called by upper layer before tx_prepare().
But if you think it could be merged into tx_prepare() into some smart and effective way -
sure thing, let's look at particular implementation ideas you have.
>
> The main question here is how invasive in packet data tx_prepare should be.
>
> If I understand you correctly, you're talking about the situation when tx_prepare will try to restore packet internally, e.g. linearize data
> for i40e to meet number of segments requirements, split mbufs, when are too large, maybe someone will wanted to have full
> software checksum computation fallback for devices which doesn't support it, and so on? And then this parameter will indicate "do
> the required work for me", or "just check, initialize what should be initialized, if fails, let me decide"?
>
> Implemented model is quite simple and clear:
>
> 1) Validate uncommon requirements which may cause a problem and let application to deal with it.
> 2) If packet is valid, initialize required fields according to the hardware requirements.
>
> In fact, it doesn't fix anything for now, but initializes checksums, and the main reason why it is done here, is the fact that it cannot be
> done in a trivial way in the application itself.
>
> IMHO, we should to keep this API as simple as it possible and not let it grow in unexpected way (also for performance reason).
>
> > About rte_eth_desc_lim->nb_seg_max and
> > rte_eth_desc_lim->nb_mtu_seg_max, I'm still quite reserved, especially for
> > the 2nd one, because I don't see how it can be used by the application.
> > Well, it does not hurt to have them, but for me it looks a bit useless.
> >
>
> * "nb_seg_max": Maximum number of segments per whole packet.
> * "nb_mtu_seg_max": Maximum number of segments per one MTU.
>
> Application can use provided values in a fallowed way:
>
> * For non-TSO packet, a single transmit packet may span up to "nb_mtu_seg_max" buffers.
> * For TSO packet the total number of data descriptors is "nb_seg_max", and each segment within the TSO may span up to
> "nb_mtu_seg_max".
I suppose these fields will be useful.
Let say you are about to form and send packets.
Right now, how would you know what are HW limitations on number of segments per packet?
>
> > Last thing, I think this API should become the default in the future.
> > For instance, it would prevent the application to calculate a phdr csum
> > that will not be used by the hw. Not calling tx_prepare() would require
> > the user/application to exactly knows the underlying hw and the kind of
> > packet that are generated. So for me it means we'll need to also update
> > other examples (other testpmd engines, l2fwd, ...). Do you agree?
> >
>
> Most of sample applications doesn't use TX offloads at all and doesn't count checksums. So the question is "should tx_prepare be
> used even if not required?"
I suppose it wouldn't be a big harm to add tx_prepare() into sample apps when appropriate.
In most cases (when simple TS path used) it will be NOP anyway.
Konstantin
^ permalink raw reply
* Re: [PATCH v11] drivers/net:new TUN/TAP device PMD
From: Vasily Philipov @ 2016-12-12 12:39 UTC (permalink / raw)
To: Keith Wiles, dev@dpdk.org
Cc: pmatilai@redhat.com, yuanhan.liu@linux.intel.com,
ferruh.yigit@intel.com, john.mcnamara@intel.com
In-Reply-To: <20161209190519.2390-1-keith.wiles@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Keith Wiles
> Sent: Friday, December 09, 2016 21:05
> To: dev@dpdk.org
> Cc: pmatilai@redhat.com; yuanhan.liu@linux.intel.com;
> ferruh.yigit@intel.com; john.mcnamara@intel.com
> Subject: [dpdk-dev] [PATCH v11] drivers/net:new TUN/TAP device PMD
>
> The PMD allows for DPDK and the host to communicate using a raw device
> interface on the host and in the DPDK application. The device created is a Tap
> device with a L2 packet header.
>
> v11- Add the tap.rst to the nic/index.rst file
> v10- Change the string name used to allow for multiple devices.
> v9 - Fix up the docs to use correct syntax
> v8 - Fix issue with tap_tx_queue_setup() not return zero on success.
> v7 - Reword the comment in common_base and fix the data->name issue
> v6 - fixed the checkpatch issues
> v5 - merge in changes from list review see related emails
> fixed many minor edits
> v4 - merge with latest driver changes
> v3 - fix includes by removing ifdef for other type besides Linux
> Fix the copyright notice in the Makefile
> v2 - merge all of the patches into one patch
> Fix a typo on naming the tap device
> Update the maintainers list
>
> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
> ---
> MAINTAINERS | 5 +
> config/common_base | 9 +
> config/common_linuxapp | 1 +
> doc/guides/nics/index.rst | 1 +
> doc/guides/nics/tap.rst | 136 ++++++
> drivers/net/Makefile | 1 +
> drivers/net/tap/Makefile | 57 +++
> drivers/net/tap/rte_eth_tap.c | 765
> ++++++++++++++++++++++++++++++++
> drivers/net/tap/rte_pmd_tap_version.map | 4 +
> mk/rte.app.mk | 1 +
> 10 files changed, 980 insertions(+)
Tested-by: Vasily Philipov <vasilyf@mellanox.com>
^ permalink raw reply
* [PATCH v3 0/9] net/ixgbe: move set VF functions.
From: Bernard Iremonger @ 2016-12-12 13:50 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481304361-16032-1-git-send-email-bernard.iremonger@intel.com>
This patchset implements the following deprecation notice:
[PATCH v1] doc: announce API and ABI change for librte_ether
Changes in V3:
Updated LIBABIVER in Makefile in librte_ether patch.
Updated rte_ethdev.h and ret_ether_version.map in librte_ether patch.
Squashed deprecation notice patch into librte_ether patch.
Added release_note patch.
Changes in V2:
Update testpmd set vf commands help messages.
Updated ethtool to use the ixgbe public API's.
Removed the ixgbe_set_pool_* and ixgbe_set_vf_rate_limit functions.
Removed the rte_eth_dev_set_vf_* API's
Removed the deprecation notice.
Changes in V1:
The following functions from eth_dev_ops have been moved to the ixgbe PMD
and renamed:
ixgbe_set_pool_rx_mode
ixgbe_set_pool_rx
ixgbe_set_pool_tx
ixgbe_set_pool_vlan_filter
ixgbe_set_vf_rate_limit
Renamed the functions to the following:
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
rte_pmd_ixgbe_set_vf_rate_limit
Testpmd has been modified to use the following functions:
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_rate_limit
New testpmd commands have been added to test the following functions:
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
The testpmd user guide has been updated for the new commands.
Bernard Iremonger (9):
net/ixgbe: move set VF functions from the ethdev
app/testpmd: use ixgbe public functions
app/testpmd: add command for set VF VLAN filter
app/testpmd: add command for set VF receive
app/testpmd: add command for set VF transmit
examples/ethtool: use ixgbe public function
net/ixgbe: remove static set VF functions
librte_ether: remove the set VF API's
doc: update release notes
app/test-pmd/cmdline.c | 270 +++++++++++++++-
app/test-pmd/config.c | 31 +-
doc/guides/rel_notes/deprecation.rst | 13 -
doc/guides/rel_notes/release_17_02.rst | 20 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 21 ++
drivers/net/ixgbe/ixgbe_ethdev.c | 459 ++++++++++++++++------------
drivers/net/ixgbe/rte_pmd_ixgbe.h | 104 +++++++
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 10 +
examples/ethtool/lib/rte_ethtool.c | 5 +-
lib/librte_ether/Makefile | 4 +-
lib/librte_ether/rte_ethdev.c | 129 --------
lib/librte_ether/rte_ethdev.h | 140 ---------
lib/librte_ether/rte_ether_version.map | 7 +-
13 files changed, 706 insertions(+), 507 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH v3 1/9] net/ixgbe: move set VF functions from the ethdev
From: Bernard Iremonger @ 2016-12-12 13:50 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481304361-16032-1-git-send-email-bernard.iremonger@intel.com>
Move the following functions from eth_dev_ops to the ixgbe PMD and rename:
ixgbe_set_pool_rx_mode
ixgbe_set_pool_rx
ixgbe_set_pool_tx
ixgbe_set_pool_vlan_filter
ixgbe_set_vf_rate_limit
Rename the functions to the following:
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
rte_pmd_ixgbe_set_vf_rate_limit
Use public function internally
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
drivers/net/ixgbe/ixgbe_ethdev.c | 266 +++++++++++++++++++++++++++-
drivers/net/ixgbe/rte_pmd_ixgbe.h | 104 +++++++++++
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 10 ++
3 files changed, 379 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index edc9b22..37b82a4 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2294,7 +2294,8 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
for (vf = 0; vf < dev->pci_dev->max_vfs; vf++)
for (idx = 0; idx < IXGBE_MAX_QUEUE_NUM_PER_VF; idx++)
if (vfinfo[vf].tx_rate[idx] != 0)
- ixgbe_set_vf_rate_limit(dev, vf,
+ rte_pmd_ixgbe_set_vf_rate_limit(
+ dev->data->port_id, vf,
vfinfo[vf].tx_rate[idx],
1 << idx);
}
@@ -4883,6 +4884,269 @@ rte_pmd_ixgbe_set_vf_vlan_stripq(uint8_t port, uint16_t vf, uint8_t on)
return 0;
}
+int
+rte_pmd_ixgbe_set_vf_rxmode(uint8_t port, uint16_t vf, uint16_t rx_mask, uint8_t on)
+{
+ int val = 0;
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ struct ixgbe_hw *hw;
+ uint32_t vmolr;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if (vf >= dev_info.max_vfs)
+ return -EINVAL;
+
+ if (on > 1)
+ return -EINVAL;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+
+ if (hw->mac.type == ixgbe_mac_82598EB) {
+ PMD_INIT_LOG(ERR, "setting VF receive mode set should be done"
+ " on 82599 hardware and newer");
+ return -ENOTSUP;
+ }
+ if (ixgbe_vmdq_mode_check(hw) < 0)
+ return -ENOTSUP;
+
+ val = ixgbe_convert_vm_rx_mask_to_val(rx_mask, val);
+
+ if (on)
+ vmolr |= val;
+ else
+ vmolr &= ~val;
+
+ IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_rx(uint8_t port, uint16_t vf, uint8_t on)
+{
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ uint32_t reg, addr;
+ uint32_t val;
+ const uint8_t bit1 = 0x1;
+ struct ixgbe_hw *hw;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if (vf >= dev_info.max_vfs)
+ return -EINVAL;
+
+ if (on > 1)
+ return -EINVAL;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ if (ixgbe_vmdq_mode_check(hw) < 0)
+ return -ENOTSUP;
+
+ /* for vf >= 32, set bit in PFVFRE[1], otherwise PFVFRE[0] */
+ if (vf >= 32) {
+ addr = IXGBE_VFRE(1);
+ val = bit1 << (vf - 32);
+ } else {
+ addr = IXGBE_VFRE(0);
+ val = bit1 << vf;
+ }
+
+ reg = IXGBE_READ_REG(hw, addr);
+
+ if (on)
+ reg |= val;
+ else
+ reg &= ~val;
+
+ IXGBE_WRITE_REG(hw, addr, reg);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_tx(uint8_t port, uint16_t vf, uint8_t on)
+{
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ uint32_t reg, addr;
+ uint32_t val;
+ const uint8_t bit1 = 0x1;
+
+ struct ixgbe_hw *hw;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if (vf >= dev_info.max_vfs)
+ return -EINVAL;
+
+ if (on > 1)
+ return -EINVAL;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ if (ixgbe_vmdq_mode_check(hw) < 0)
+ return -ENOTSUP;
+
+ /* for vf >= 32, set bit in PFVFTE[1], otherwise PFVFTE[0] */
+ if (vf >= 32) {
+ addr = IXGBE_VFTE(1);
+ val = bit1 << (vf - 32);
+ } else {
+ addr = IXGBE_VFTE(0);
+ val = bit1 << vf;
+ }
+
+ reg = IXGBE_READ_REG(hw, addr);
+
+ if (on)
+ reg |= val;
+ else
+ reg &= ~val;
+
+ IXGBE_WRITE_REG(hw, addr, reg);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_vlan_filter(uint8_t port, uint16_t vlan,
+ uint64_t vf_mask, uint8_t vlan_on)
+{
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ int ret = 0;
+ uint16_t vf_idx;
+ struct ixgbe_hw *hw;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if ((vlan > ETHER_MAX_VLAN_ID) || (vf_mask == 0))
+ return -EINVAL;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ if (ixgbe_vmdq_mode_check(hw) < 0)
+ return -ENOTSUP;
+
+ for (vf_idx = 0; vf_idx < 64; vf_idx++) {
+ if (vf_mask & ((uint64_t)(1ULL << vf_idx))) {
+ ret = hw->mac.ops.set_vfta(hw, vlan, vf_idx,
+ vlan_on, false);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+int rte_pmd_ixgbe_set_vf_rate_limit(uint8_t port, uint16_t vf,
+ uint16_t tx_rate, uint64_t q_msk)
+{
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ struct ixgbe_hw *hw;
+ struct ixgbe_vf_info *vfinfo;
+ struct rte_eth_link link;
+ uint8_t nb_q_per_pool;
+ uint32_t queue_stride;
+ uint32_t queue_idx, idx = 0, vf_idx;
+ uint32_t queue_end;
+ uint16_t total_rate = 0;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+ rte_eth_link_get_nowait(port, &link);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if (vf >= dev_info.max_vfs)
+ return -EINVAL;
+
+ if (tx_rate > link.link_speed)
+ return -EINVAL;
+
+ if (q_msk == 0)
+ return 0;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ vfinfo = *(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
+ nb_q_per_pool = RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
+ queue_stride = IXGBE_MAX_RX_QUEUE_NUM / RTE_ETH_DEV_SRIOV(dev).active;
+ queue_idx = vf * queue_stride;
+ queue_end = queue_idx + nb_q_per_pool - 1;
+ if (queue_end >= hw->mac.max_tx_queues)
+ return -EINVAL;
+
+ if (vfinfo) {
+ for (vf_idx = 0; vf_idx < dev->pci_dev->max_vfs; vf_idx++) {
+ if (vf_idx == vf)
+ continue;
+ for (idx = 0; idx < RTE_DIM(vfinfo[vf_idx].tx_rate);
+ idx++)
+ total_rate += vfinfo[vf_idx].tx_rate[idx];
+ }
+ } else {
+ return -EINVAL;
+ }
+
+ /* Store tx_rate for this vf. */
+ for (idx = 0; idx < nb_q_per_pool; idx++) {
+ if (((uint64_t)0x1 << idx) & q_msk) {
+ if (vfinfo[vf].tx_rate[idx] != tx_rate)
+ vfinfo[vf].tx_rate[idx] = tx_rate;
+ total_rate += tx_rate;
+ }
+ }
+
+ if (total_rate > dev->data->dev_link.link_speed) {
+ /* Reset stored TX rate of the VF if it causes exceed
+ * link speed.
+ */
+ memset(vfinfo[vf].tx_rate, 0, sizeof(vfinfo[vf].tx_rate));
+ return -EINVAL;
+ }
+
+ /* Set RTTBCNRC of each queue/pool for vf X */
+ for (; queue_idx <= queue_end; queue_idx++) {
+ if (0x1 & q_msk)
+ ixgbe_set_queue_rate_limit(dev, queue_idx, tx_rate);
+ q_msk = q_msk >> 1;
+ }
+
+ return 0;
+}
+
#define IXGBE_MRCTL_VPME 0x01 /* Virtual Pool Mirroring. */
#define IXGBE_MRCTL_UPME 0x02 /* Uplink Port Mirroring. */
#define IXGBE_MRCTL_DPME 0x04 /* Downlink Port Mirroring. */
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.h b/drivers/net/ixgbe/rte_pmd_ixgbe.h
index c2fb826..4eb0c9a 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe.h
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe.h
@@ -183,6 +183,110 @@ int
rte_pmd_ixgbe_set_vf_vlan_stripq(uint8_t port, uint16_t vf, uint8_t on);
/**
+* Set RX L2 Filtering mode of a VF of an Ethernet device.
+*
+* @param port
+* The port identifier of the Ethernet device.
+* @param vf
+* VF id.
+* @param rx_mode
+* The RX mode mask, which is one or more of accepting Untagged Packets,
+* packets that match the PFUTA table, Broadcast and Multicast Promiscuous.
+* ETH_VMDQ_ACCEPT_UNTAG,ETH_VMDQ_ACCEPT_HASH_UC,
+* ETH_VMDQ_ACCEPT_BROADCAST and ETH_VMDQ_ACCEPT_MULTICAST will be used
+* in rx_mode.
+* @param on
+* 1 - Enable a VF RX mode.
+* 0 - Disable a VF RX mode.
+* @return
+* - (0) if successful.
+* - (-ENOTSUP) if hardware doesn't support.
+* - (-ENODEV) if *port_id* invalid.
+* - (-EINVAL) if bad parameter.
+*/
+int
+rte_pmd_ixgbe_set_vf_rxmode(uint8_t port, uint16_t vf, uint16_t rx_mask, uint8_t on);
+
+/**
+* Enable or disable a VF traffic receive of an Ethernet device.
+*
+* @param port
+* The port identifier of the Ethernet device.
+* @param vf
+* VF id.
+* @param on
+* 1 - Enable a VF traffic receive.
+* 0 - Disable a VF traffic receive.
+* @return
+* - (0) if successful.
+* - (-ENOTSUP) if hardware doesn't support.
+* - (-ENODEV) if *port_id* invalid.
+* - (-EINVAL) if bad parameter.
+*/
+int
+rte_pmd_ixgbe_set_vf_rx(uint8_t port, uint16_t vf, uint8_t on);
+
+/**
+* Enable or disable a VF traffic transmit of the Ethernet device.
+*
+* @param port
+* The port identifier of the Ethernet device.
+* @param vf
+* VF id.
+* @param on
+* 1 - Enable a VF traffic transmit.
+* 0 - Disable a VF traffic transmit.
+* @return
+* - (0) if successful.
+* - (-ENODEV) if *port_id* invalid.
+* - (-ENOTSUP) if hardware doesn't support.
+* - (-EINVAL) if bad parameter.
+*/
+int
+rte_pmd_ixgbe_set_vf_tx(uint8_t port, uint16_t vf, uint8_t on);
+
+/**
+* Enable/Disable hardware VF VLAN filtering by an Ethernet device of
+* received VLAN packets tagged with a given VLAN Tag Identifier.
+*
+* @param port id
+* The port identifier of the Ethernet device.
+* @param vlan_id
+* The VLAN Tag Identifier whose filtering must be enabled or disabled.
+* @param vf_mask
+* Bitmap listing which VFs participate in the VLAN filtering.
+* @param vlan_on
+* 1 - Enable VFs VLAN filtering.
+* 0 - Disable VFs VLAN filtering.
+* @return
+* - (0) if successful.
+* - (-ENOTSUP) if hardware doesn't support.
+* - (-ENODEV) if *port_id* invalid.
+* - (-EINVAL) if bad parameter.
+*/
+int
+rte_pmd_ixgbe_set_vf_vlan_filter(uint8_t port, uint16_t vlan, uint64_t vf_mask, uint8_t vlan_on);
+
+/**
+ * Set the rate limitation for a vf on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param vf
+ * VF id.
+ * @param tx_rate
+ * The tx rate allocated from the total link speed for this VF id.
+ * @param q_msk
+ * The queue mask which need to set the rate.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if hardware doesn't support this feature.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+int rte_pmd_ixgbe_set_vf_rate_limit(uint8_t port, uint16_t vf, uint16_t tx_rate, uint64_t q_msk);
+
+/**
* Response sent back to ixgbe driver from user app after callback
*/
enum rte_pmd_ixgbe_mb_event_rsp {
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
index 92434f3..5252bc2 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
@@ -15,3 +15,13 @@ DPDK_16.11 {
rte_pmd_ixgbe_set_vf_vlan_insert;
rte_pmd_ixgbe_set_vf_vlan_stripq;
} DPDK_2.0;
+
+DPDK_17.02 {
+ global:
+
+ rte_pmd_ixgbe_set_vf_rate_limit;
+ rte_pmd_ixgbe_set_vf_rx;
+ rte_pmd_ixgbe_set_vf_rxmode;
+ rte_pmd_ixgbe_set_vf_tx;
+ rte_pmd_ixgbe_set_vf_vlan_filter;
+} DPDK_16.11;
\ No newline at end of file
--
2.10.1
^ permalink raw reply related
* [PATCH v3 2/9] app/testpmd: use ixgbe public functions
From: Bernard Iremonger @ 2016-12-12 13:50 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481304361-16032-1-git-send-email-bernard.iremonger@intel.com>
Use the the following ixgbe public functions:
rte_pmd_ixgbe_set_vf_rate_limit
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
app/test-pmd/cmdline.c | 2 +-
app/test-pmd/config.c | 31 +++++++++++--------------------
2 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d03a592..12f799b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6708,7 +6708,7 @@ cmd_set_vf_rxmode_parsed(void *parsed_result,
rx_mode |= ETH_VMDQ_ACCEPT_MULTICAST;
}
- ret = rte_eth_dev_set_vf_rxmode(res->port_id,res->vf_id,rx_mode,(uint8_t)is_on);
+ ret = rte_pmd_ixgbe_set_vf_rxmode(res->port_id, res->vf_id, rx_mode, (uint8_t)is_on);
if (ret < 0)
printf("bad VF receive mode parameter, return code = %d \n",
ret);
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 8cf537d..ea129db 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -92,6 +92,9 @@
#include <rte_ethdev.h>
#include <rte_string_fns.h>
#include <rte_cycles.h>
+#ifdef RTE_LIBRTE_IXGBE_PMD
+#include <rte_pmd_ixgbe.h>
+#endif
#include "testpmd.h"
@@ -2332,16 +2335,16 @@ set_vf_traffic(portid_t port_id, uint8_t is_rx, uint16_t vf, uint8_t on)
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
if (is_rx)
- diag = rte_eth_dev_set_vf_rx(port_id,vf,on);
+ diag = rte_pmd_ixgbe_set_vf_rx(port_id, vf, on);
else
- diag = rte_eth_dev_set_vf_tx(port_id,vf,on);
+ diag = rte_pmd_ixgbe_set_vf_tx(port_id, vf, on);
if (diag == 0)
return;
if(is_rx)
- printf("rte_eth_dev_set_vf_rx for port_id=%d failed "
+ printf("rte_pmd_ixgbe_set_vf_rx for port_id=%d failed "
"diag=%d\n", port_id, diag);
else
- printf("rte_eth_dev_set_vf_tx for port_id=%d failed "
+ printf("rte_pmd_ixgbe_set_vf_tx for port_id=%d failed "
"diag=%d\n", port_id, diag);
}
@@ -2355,10 +2358,10 @@ set_vf_rx_vlan(portid_t port_id, uint16_t vlan_id, uint64_t vf_mask, uint8_t on)
return;
if (vlan_id_is_invalid(vlan_id))
return;
- diag = rte_eth_dev_set_vf_vlan_filter(port_id, vlan_id, vf_mask, on);
+ diag = rte_pmd_ixgbe_set_vf_vlan_filter(port_id, vlan_id, vf_mask, on);
if (diag == 0)
return;
- printf("rte_eth_dev_set_vf_vlan_filter for port_id=%d failed "
+ printf("rte_pmd_ixgbe_set_vf_vlan_filter for port_id=%d failed "
"diag=%d\n", port_id, diag);
}
@@ -2388,23 +2391,11 @@ int
set_vf_rate_limit(portid_t port_id, uint16_t vf, uint16_t rate, uint64_t q_msk)
{
int diag;
- struct rte_eth_link link;
-
- if (q_msk == 0)
- return 0;
- if (port_id_is_invalid(port_id, ENABLED_WARN))
- return 1;
- rte_eth_link_get_nowait(port_id, &link);
- if (rate > link.link_speed) {
- printf("Invalid rate value:%u bigger than link speed: %u\n",
- rate, link.link_speed);
- return 1;
- }
- diag = rte_eth_set_vf_rate_limit(port_id, vf, rate, q_msk);
+ diag = rte_pmd_ixgbe_set_vf_rate_limit(port_id, vf, rate, q_msk);
if (diag == 0)
return diag;
- printf("rte_eth_set_vf_rate_limit for port_id=%d failed diag=%d\n",
+ printf("rte_pmd_ixgbe_set_vf_rate_limit for port_id=%d failed diag=%d\n",
port_id, diag);
return diag;
}
--
2.10.1
^ permalink raw reply related
* [PATCH v3 3/9] app/testpmd: add command for set VF VLAN filter
From: Bernard Iremonger @ 2016-12-12 13:50 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481304361-16032-1-git-send-email-bernard.iremonger@intel.com>
Add the following command to testpmd:
set vf vlan filter <port_id> <vlan_id> <vf_mask> on|off
Add command to the testpmd user guide.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
app/test-pmd/cmdline.c | 98 +++++++++++++++++++++++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++
2 files changed, 105 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 12f799b..947c698 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -291,6 +291,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"set vf vlan antispoof (port_id) (vf_id) (on|off)\n"
" Set VLAN antispoof for a VF from the PF.\n\n"
+
+ "set vf vlan filter (port_id) (vlan_id) (vf_mask) (on|off)\n"
+ " Set VLAN filter for a VF pool from the PF.\n\n"
#endif
"vlan set filter (on|off) (port_id)\n"
@@ -11139,6 +11142,100 @@ cmdline_parse_inst_t cmd_set_vf_vlan_insert = {
},
};
+
+/* vf vlan filter configuration */
+
+/* Common result structure for vf vlan filter */
+struct cmd_vf_vlan_filter_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t vf;
+ cmdline_fixed_string_t vlan;
+ cmdline_fixed_string_t filter;
+ uint8_t port_id;
+ uint16_t vlan_id;
+ uint16_t vf_mask;
+ cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf vlan filter enable disable */
+cmdline_parse_token_string_t cmd_vf_vlan_filter_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_vf_vlan_filter_vf =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ vf, "vf");
+cmdline_parse_token_string_t cmd_vf_vlan_filter_vlan =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ vlan, "vlan");
+cmdline_parse_token_string_t cmd_vf_vlan_filter_filter =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ filter, "filter");
+cmdline_parse_token_num_t cmd_vf_vlan_filter_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ port_id, UINT8);
+cmdline_parse_token_num_t cmd_vf_vlan_filter_vlan_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ vlan_id, UINT16);
+cmdline_parse_token_num_t cmd_vf_vlan_filter_vf_mask =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ vf_mask, UINT16);
+cmdline_parse_token_string_t cmd_vf_vlan_filter_on_off =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ on_off, "on#off");
+
+static void
+cmd_set_vf_vlan_filter_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_vf_vlan_filter_result *res = parsed_result;
+ int ret;
+ int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+
+ ret = rte_pmd_ixgbe_set_vf_vlan_filter(res->port_id, res->vlan_id, res->vf_mask, is_on);
+ switch (ret) {
+ case 0:
+ break;
+ case -EINVAL:
+ printf("invalid vf_mask %d or vlan_id %d\n", res->vf_mask, res->vlan_id);
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", res->port_id);
+ break;
+ case -ENOTSUP:
+ printf("not supported on vf port %d\n", res->port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_vf_vlan_filter = {
+ .f = cmd_set_vf_vlan_filter_parsed,
+ .data = NULL,
+ .help_str = "set vf vlan filter <port_id> <vlan_id> <vf_mask> on|off",
+ .tokens = {
+ (void *)&cmd_vf_vlan_filter_set,
+ (void *)&cmd_vf_vlan_filter_vf,
+ (void *)&cmd_vf_vlan_filter_vlan,
+ (void *)&cmd_vf_vlan_filter_filter,
+ (void *)&cmd_vf_vlan_filter_port_id,
+ (void *)&cmd_vf_vlan_filter_vlan_id,
+ (void *)&cmd_vf_vlan_filter_vf_mask,
+ (void *)&cmd_vf_vlan_filter_on_off,
+ NULL,
+ },
+};
+
/* tx loopback configuration */
/* Common result structure for tx loopback */
@@ -11620,6 +11717,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_vf_mac_anti_spoof,
(cmdline_parse_inst_t *)&cmd_set_vf_vlan_stripq,
(cmdline_parse_inst_t *)&cmd_set_vf_vlan_insert,
+ (cmdline_parse_inst_t *)&cmd_set_vf_vlan_filter,
(cmdline_parse_inst_t *)&cmd_set_tx_loopback,
(cmdline_parse_inst_t *)&cmd_set_all_queues_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index f1c269a..60dcd91 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -535,6 +535,13 @@ Set VLAN insert for a VF from the PF::
testpmd> set vf vlan insert (port_id) (vf_id) (vlan_id)
+vlan set filter (for VF pool)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Set VLAN filter for a VF pool from the PF::
+
+ testpmd> set vf vlan filter (port_id) (vlan_id) (vf_mask) (on|off)
+
vlan set antispoof (for VF)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.10.1
^ permalink raw reply related
* [PATCH v3 4/9] app/testpmd: add command for set VF receive
From: Bernard Iremonger @ 2016-12-12 13:50 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481304361-16032-1-git-send-email-bernard.iremonger@intel.com>
add the following command to testpmd:
set vf rx <port_id> <vf_id> on|off
add command to the testpmd user guide.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
app/test-pmd/cmdline.c | 85 +++++++++++++++++++++++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++
2 files changed, 92 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 947c698..4424c0a 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -274,6 +274,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"set vf mac antispoof (port_id) (vf_id) (on|off).\n"
" Set MAC antispoof for a VF from the PF.\n\n"
+
+ "set vf rx (port_id) (vf_id) (on|off).\n"
+ " Enable or disable RX for a VF from the PF.\n\n"
#endif
"vlan set strip (on|off) (port_id)\n"
@@ -11236,6 +11239,87 @@ cmdline_parse_inst_t cmd_set_vf_vlan_filter = {
},
};
+/* vf rx configuration */
+
+/* Common result structure for vf rx */
+struct cmd_vf_rx_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t vf;
+ cmdline_fixed_string_t rx;
+ uint8_t port_id;
+ uint16_t vf_id;
+ cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf rx enable disable */
+cmdline_parse_token_string_t cmd_vf_rx_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_rx_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_vf_rx_vf =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_rx_result,
+ vf, "vf");
+cmdline_parse_token_string_t cmd_vf_rx_rx =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_rx_result,
+ rx, "rx");
+cmdline_parse_token_num_t cmd_vf_rx_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_rx_result,
+ port_id, UINT8);
+cmdline_parse_token_num_t cmd_vf_rx_vf_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_rx_result,
+ vf_id, UINT16);
+cmdline_parse_token_string_t cmd_vf_rx_on_off =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_rx_result,
+ on_off, "on#off");
+
+static void
+cmd_set_vf_rx_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_vf_rx_result *res = parsed_result;
+ int ret = 0;
+ int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+
+ ret = rte_pmd_ixgbe_set_vf_rx(res->port_id, res->vf_id, is_on);
+ switch (ret) {
+ case 0:
+ break;
+ case -EINVAL:
+ printf("invalid vf_id %d or is_on %d\n", res->vf_id, is_on);
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", res->port_id);
+ break;
+ case -ENOTSUP:
+ printf("not supported on vf port %d\n", res->port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_vf_rx = {
+ .f = cmd_set_vf_rx_parsed,
+ .data = NULL,
+ .help_str = "set vf rx <port_id> <vf_id> on|off",
+ .tokens = {
+ (void *)&cmd_vf_rx_set,
+ (void *)&cmd_vf_rx_vf,
+ (void *)&cmd_vf_rx_rx,
+ (void *)&cmd_vf_rx_port_id,
+ (void *)&cmd_vf_rx_vf_id,
+ (void *)&cmd_vf_rx_on_off,
+ NULL,
+ },
+};
+
/* tx loopback configuration */
/* Common result structure for tx loopback */
@@ -11722,6 +11806,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_all_queues_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_mac_addr,
+ (cmdline_parse_inst_t *)&cmd_set_vf_rx,
#endif
NULL,
};
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 60dcd91..6a058e9 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -507,6 +507,13 @@ Set mac antispoof for a VF from the PF::
testpmd> set vf mac antispoof (port_id) (vf_id) (on|off)
+set rx (for VF)
+~~~~~~~~~~~~~~~
+
+Enable/disable rx for a VF from the PF::
+
+ testpmd> set vf rx (port_id) (vf_id) (on|off)
+
vlan set strip
~~~~~~~~~~~~~~
--
2.10.1
^ permalink raw reply related
* [PATCH v3 5/9] app/testpmd: add command for set VF transmit
From: Bernard Iremonger @ 2016-12-12 13:50 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481304361-16032-1-git-send-email-bernard.iremonger@intel.com>
add the following command to testpmd:
set vf tx <port_id> <vf_id> on|off
add command to the testpmd user guide.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
app/test-pmd/cmdline.c | 85 +++++++++++++++++++++++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++
2 files changed, 92 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 4424c0a..e385732 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -277,6 +277,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"set vf rx (port_id) (vf_id) (on|off).\n"
" Enable or disable RX for a VF from the PF.\n\n"
+
+ "set vf tx (port_id) (vf_id) (on|off).\n"
+ " Enable or disable TX for a VF from the PF.\n\n"
#endif
"vlan set strip (on|off) (port_id)\n"
@@ -11320,6 +11323,87 @@ cmdline_parse_inst_t cmd_set_vf_rx = {
},
};
+/* vf tx configuration */
+
+/* Common result structure for vf tx */
+struct cmd_vf_tx_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t vf;
+ cmdline_fixed_string_t tx;
+ uint8_t port_id;
+ uint16_t vf_id;
+ cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf tx enable disable */
+cmdline_parse_token_string_t cmd_vf_tx_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_tx_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_vf_tx_vf =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_tx_result,
+ vf, "vf");
+cmdline_parse_token_string_t cmd_vf_tx_tx =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_tx_result,
+ tx, "tx");
+cmdline_parse_token_num_t cmd_vf_tx_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_tx_result,
+ port_id, UINT8);
+cmdline_parse_token_num_t cmd_vf_tx_vf_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_tx_result,
+ vf_id, UINT16);
+cmdline_parse_token_string_t cmd_vf_tx_on_off =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_tx_result,
+ on_off, "on#off");
+
+static void
+cmd_set_vf_tx_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_vf_tx_result *res = parsed_result;
+ int ret = 0;
+ int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+
+ ret = rte_pmd_ixgbe_set_vf_tx(res->port_id, res->vf_id, is_on);
+ switch (ret) {
+ case 0:
+ break;
+ case -EINVAL:
+ printf("invalid vf_id %d or is_on %d\n", res->vf_id, is_on);
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", res->port_id);
+ break;
+ case -ENOTSUP:
+ printf("not supported on vf port %d\n", res->port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_vf_tx = {
+ .f = cmd_set_vf_tx_parsed,
+ .data = NULL,
+ .help_str = "set vf tx <port_id> <vf_id> on|off",
+ .tokens = {
+ (void *)&cmd_vf_tx_set,
+ (void *)&cmd_vf_tx_vf,
+ (void *)&cmd_vf_tx_tx,
+ (void *)&cmd_vf_tx_port_id,
+ (void *)&cmd_vf_tx_vf_id,
+ (void *)&cmd_vf_tx_on_off,
+ NULL,
+ },
+};
+
/* tx loopback configuration */
/* Common result structure for tx loopback */
@@ -11807,6 +11891,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_mac_addr,
(cmdline_parse_inst_t *)&cmd_set_vf_rx,
+ (cmdline_parse_inst_t *)&cmd_set_vf_tx,
#endif
NULL,
};
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 6a058e9..1de4c5f 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -514,6 +514,13 @@ Enable/disable rx for a VF from the PF::
testpmd> set vf rx (port_id) (vf_id) (on|off)
+set tx (for VF)
+~~~~~~~~~~~~~~~
+
+Enable/disable tx for a VF from the PF::
+
+ testpmd> set vf tx (port_id) (vf_id) (on|off)
+
vlan set strip
~~~~~~~~~~~~~~
--
2.10.1
^ permalink raw reply related
* [PATCH v3 6/9] examples/ethtool: use ixgbe public function
From: Bernard Iremonger @ 2016-12-12 13:50 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481304361-16032-1-git-send-email-bernard.iremonger@intel.com>
Replace rte_eth_dev_set_vf_rxmode with rte_pmd_ixgbe_set_vf_rx_mode.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
examples/ethtool/lib/rte_ethtool.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/examples/ethtool/lib/rte_ethtool.c b/examples/ethtool/lib/rte_ethtool.c
index a1f91d4..0e539f7 100644
--- a/examples/ethtool/lib/rte_ethtool.c
+++ b/examples/ethtool/lib/rte_ethtool.c
@@ -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
@@ -36,6 +36,7 @@
#include <rte_version.h>
#include <rte_ethdev.h>
#include <rte_ether.h>
+#include <rte_pmd_ixgbe.h>
#include "rte_ethtool.h"
#define PKTPOOL_SIZE 512
@@ -354,7 +355,7 @@ rte_ethtool_net_set_rx_mode(uint8_t port_id)
/* Set VF vf_rx_mode, VF unsupport status is discard */
for (vf = 0; vf < num_vfs; vf++)
- rte_eth_dev_set_vf_rxmode(port_id, vf,
+ rte_pmd_ixgbe_set_vf_rxmode(port_id, vf,
ETH_VMDQ_ACCEPT_UNTAG, 0);
/* Enable Rx vlan filter, VF unspport status is discard */
--
2.10.1
^ permalink raw reply related
* [PATCH v3 7/9] net/ixgbe: remove static set VF functions
From: Bernard Iremonger @ 2016-12-12 13:50 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481304361-16032-1-git-send-email-bernard.iremonger@intel.com>
remove the following static functions:
ixgbe_set_pool_rx_mode
ixgbe_set_pool_rx
ixgbe_set_pool_tx
ixgbe_set_pool_vlan_filter
ixgbe_set_vf_rate_limit
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
drivers/net/ixgbe/ixgbe_ethdev.c | 193 ---------------------------------------
1 file changed, 193 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 37b82a4..8db1410 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -276,12 +276,6 @@ static void ixgbevf_dev_allmulticast_disable(struct rte_eth_dev *dev);
static int ixgbe_uc_hash_table_set(struct rte_eth_dev *dev, struct
ether_addr * mac_addr, uint8_t on);
static int ixgbe_uc_all_hash_table_set(struct rte_eth_dev *dev, uint8_t on);
-static int ixgbe_set_pool_rx_mode(struct rte_eth_dev *dev, uint16_t pool,
- uint16_t rx_mask, uint8_t on);
-static int ixgbe_set_pool_rx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on);
-static int ixgbe_set_pool_tx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on);
-static int ixgbe_set_pool_vlan_filter(struct rte_eth_dev *dev, uint16_t vlan,
- uint64_t pool_mask, uint8_t vlan_on);
static int ixgbe_mirror_rule_set(struct rte_eth_dev *dev,
struct rte_eth_mirror_conf *mirror_conf,
uint8_t rule_id, uint8_t on);
@@ -297,8 +291,6 @@ static void ixgbe_configure_msix(struct rte_eth_dev *dev);
static int ixgbe_set_queue_rate_limit(struct rte_eth_dev *dev,
uint16_t queue_idx, uint16_t tx_rate);
-static int ixgbe_set_vf_rate_limit(struct rte_eth_dev *dev, uint16_t vf,
- uint16_t tx_rate, uint64_t q_msk);
static void ixgbevf_add_mac_addr(struct rte_eth_dev *dev,
struct ether_addr *mac_addr,
@@ -568,12 +560,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.uc_all_hash_table_set = ixgbe_uc_all_hash_table_set,
.mirror_rule_set = ixgbe_mirror_rule_set,
.mirror_rule_reset = ixgbe_mirror_rule_reset,
- .set_vf_rx_mode = ixgbe_set_pool_rx_mode,
- .set_vf_rx = ixgbe_set_pool_rx,
- .set_vf_tx = ixgbe_set_pool_tx,
- .set_vf_vlan_filter = ixgbe_set_pool_vlan_filter,
.set_queue_rate_limit = ixgbe_set_queue_rate_limit,
- .set_vf_rate_limit = ixgbe_set_vf_rate_limit,
.reta_update = ixgbe_dev_rss_reta_update,
.reta_query = ixgbe_dev_rss_reta_query,
#ifdef RTE_NIC_BYPASS
@@ -4547,132 +4534,6 @@ ixgbe_convert_vm_rx_mask_to_val(uint16_t rx_mask, uint32_t orig_val)
return new_val;
}
-static int
-ixgbe_set_pool_rx_mode(struct rte_eth_dev *dev, uint16_t pool,
- uint16_t rx_mask, uint8_t on)
-{
- int val = 0;
-
- struct ixgbe_hw *hw =
- IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- uint32_t vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(pool));
-
- if (hw->mac.type == ixgbe_mac_82598EB) {
- PMD_INIT_LOG(ERR, "setting VF receive mode set should be done"
- " on 82599 hardware and newer");
- return -ENOTSUP;
- }
- if (ixgbe_vmdq_mode_check(hw) < 0)
- return -ENOTSUP;
-
- val = ixgbe_convert_vm_rx_mask_to_val(rx_mask, val);
-
- if (on)
- vmolr |= val;
- else
- vmolr &= ~val;
-
- IXGBE_WRITE_REG(hw, IXGBE_VMOLR(pool), vmolr);
-
- return 0;
-}
-
-static int
-ixgbe_set_pool_rx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on)
-{
- uint32_t reg, addr;
- uint32_t val;
- const uint8_t bit1 = 0x1;
-
- struct ixgbe_hw *hw =
- IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
- if (ixgbe_vmdq_mode_check(hw) < 0)
- return -ENOTSUP;
-
- if (pool >= ETH_64_POOLS)
- return -EINVAL;
-
- /* for pool >= 32, set bit in PFVFRE[1], otherwise PFVFRE[0] */
- if (pool >= 32) {
- addr = IXGBE_VFRE(1);
- val = bit1 << (pool - 32);
- } else {
- addr = IXGBE_VFRE(0);
- val = bit1 << pool;
- }
-
- reg = IXGBE_READ_REG(hw, addr);
-
- if (on)
- reg |= val;
- else
- reg &= ~val;
-
- IXGBE_WRITE_REG(hw, addr, reg);
-
- return 0;
-}
-
-static int
-ixgbe_set_pool_tx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on)
-{
- uint32_t reg, addr;
- uint32_t val;
- const uint8_t bit1 = 0x1;
-
- struct ixgbe_hw *hw =
- IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
- if (ixgbe_vmdq_mode_check(hw) < 0)
- return -ENOTSUP;
-
- if (pool >= ETH_64_POOLS)
- return -EINVAL;
-
- /* for pool >= 32, set bit in PFVFTE[1], otherwise PFVFTE[0] */
- if (pool >= 32) {
- addr = IXGBE_VFTE(1);
- val = bit1 << (pool - 32);
- } else {
- addr = IXGBE_VFTE(0);
- val = bit1 << pool;
- }
-
- reg = IXGBE_READ_REG(hw, addr);
-
- if (on)
- reg |= val;
- else
- reg &= ~val;
-
- IXGBE_WRITE_REG(hw, addr, reg);
-
- return 0;
-}
-
-static int
-ixgbe_set_pool_vlan_filter(struct rte_eth_dev *dev, uint16_t vlan,
- uint64_t pool_mask, uint8_t vlan_on)
-{
- int ret = 0;
- uint16_t pool_idx;
- struct ixgbe_hw *hw =
- IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
- if (ixgbe_vmdq_mode_check(hw) < 0)
- return -ENOTSUP;
- for (pool_idx = 0; pool_idx < ETH_64_POOLS; pool_idx++) {
- if (pool_mask & ((uint64_t)(1ULL << pool_idx))) {
- ret = hw->mac.ops.set_vfta(hw, vlan, pool_idx,
- vlan_on, false);
- if (ret < 0)
- return ret;
- }
- }
-
- return ret;
-}
int
rte_pmd_ixgbe_set_vf_vlan_anti_spoof(uint8_t port, uint16_t vf, uint8_t on)
@@ -5628,60 +5489,6 @@ static int ixgbe_set_queue_rate_limit(struct rte_eth_dev *dev,
return 0;
}
-static int ixgbe_set_vf_rate_limit(struct rte_eth_dev *dev, uint16_t vf,
- uint16_t tx_rate, uint64_t q_msk)
-{
- struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- struct ixgbe_vf_info *vfinfo =
- *(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
- uint8_t nb_q_per_pool = RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
- uint32_t queue_stride =
- IXGBE_MAX_RX_QUEUE_NUM / RTE_ETH_DEV_SRIOV(dev).active;
- uint32_t queue_idx = vf * queue_stride, idx = 0, vf_idx;
- uint32_t queue_end = queue_idx + nb_q_per_pool - 1;
- uint16_t total_rate = 0;
-
- if (queue_end >= hw->mac.max_tx_queues)
- return -EINVAL;
-
- if (vfinfo != NULL) {
- for (vf_idx = 0; vf_idx < dev->pci_dev->max_vfs; vf_idx++) {
- if (vf_idx == vf)
- continue;
- for (idx = 0; idx < RTE_DIM(vfinfo[vf_idx].tx_rate);
- idx++)
- total_rate += vfinfo[vf_idx].tx_rate[idx];
- }
- } else
- return -EINVAL;
-
- /* Store tx_rate for this vf. */
- for (idx = 0; idx < nb_q_per_pool; idx++) {
- if (((uint64_t)0x1 << idx) & q_msk) {
- if (vfinfo[vf].tx_rate[idx] != tx_rate)
- vfinfo[vf].tx_rate[idx] = tx_rate;
- total_rate += tx_rate;
- }
- }
-
- if (total_rate > dev->data->dev_link.link_speed) {
- /*
- * Reset stored TX rate of the VF if it causes exceed
- * link speed.
- */
- memset(vfinfo[vf].tx_rate, 0, sizeof(vfinfo[vf].tx_rate));
- return -EINVAL;
- }
-
- /* Set RTTBCNRC of each queue/pool for vf X */
- for (; queue_idx <= queue_end; queue_idx++) {
- if (0x1 & q_msk)
- ixgbe_set_queue_rate_limit(dev, queue_idx, tx_rate);
- q_msk = q_msk >> 1;
- }
-
- return 0;
-}
static void
ixgbevf_add_mac_addr(struct rte_eth_dev *dev, struct ether_addr *mac_addr,
--
2.10.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox