[dpdk-dev] Q on rte hash table
Hello,
Using dpdk 19.11 and trying to understand the index returned by
'rte_hash_add_key', API says
...
* - A positive value that can be used by the caller as an offset into an
* array of user data. This value is unique for this key.
*/
int32_t
rte_hash_add_key(const struct rte_hash *h, const void *key);
I create hash with 64 entries and other params as follows
struct rte_hash_parameters user_params = {
.name = "test_hash",
.entries = 64,
.key_len = sizeof(uint32_t),
.hash_func = rte_hash_crc,
.hash_func_init_val = 0,
};
Extra flags has
extra_flag =
RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY |
RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD;
user_hash_tbl = rte_hash_create(&user_params);
When I add a key to the table I was expecting returned index to be in the
range '0 - 63'
user_idx = rte_hash_add_key(user_hash_tbl, (void *)&user_id);
However, I am seeing user_idx values 127, 128, ...
Due to MULTI_WRITE_ADD num_of_slots is calculated is as follows when
creating a table.
num_key_slots = params->entries + (RTE_MAX_LCORE - 1) *
(LCORE_CACHE_SIZE - 1) + 1;
with RTE_MAX_LCORE = 255, LCORE_CACHE_SIZE = 64
num_key_slots come to 16067
In my case the user_idx range can be '0 - 16067' . Is this correct?
Thanks,
Ravi
[dpdk-dev] Q on l3fwd-acl and acl library
Hello,
I am using l3fwd-acl example code and would like to know the intention of
ACL_DENY_SIGNATURE in the code.
Is ACL rules programmed to drop packets and not for any other
functionality? I see that userdata is ignored for ACL and programmed with
ACL_DENY_SIGNATURE + count. After classification, results are checked and
packets forwarded or dropped as in send_one_packet
static inline void
send_one_packet(struct rte_mbuf *m, uint32_t res)
{
if (likely((res & ACL_DENY_SIGNATURE) == 0 && res != 0)) {
/* forward packets */
send_single_packet(m,
(uint8_t)(res - FWD_PORT_SHIFT));
...
}
In the ACL case, "res" is always (ACL_DENY_SIGNATURE + acl_cnt) and packets
are dropped.
Is this correct?
Looking at the acl library I did not see statistics associated with the
rules so the library doesn't provide anything related to statistics?
Finally, I see the acl library has api 'rte_acl_add_rules' but nothing on
modifying/deleting existing rules?
Thanks,
Ravi
[dpdk-dev] Q on IXGBE (dpdk 19.11)
DPDK team, I have a use-case for multicast and wanted to know the current behavior of ixgbe pf and vf driver so my understanding is correct. use-case: 2 VF's (vf1 and vf2 ) from ixgbe is assigned to 2 VM's (vm1 and vm2) vf1 -- registers to mcast 01:00:5e:00:00:01, 01:00:5e:00:00:0a vf2 -- registers to mcast 01:00:5e:00:00:0a Flow: ixgbe_update_mc_addr_list_vf creates a vector based on bits to be used. /* use bits [47:36] of the address */ /* use bits [46:35] of the address */ /* use bits [45:34] of the address */ /* use bits [43:32] of the address */ VFs (vf1 and vf2) sends IXGBE_VF_SET_MULTICAST to PF PF processes IXGBE_VF_SET_MULTICAST in ixgbe_vf_set_multicast Reads IXGBE_READ_REG(hw, IXGBE_VMOLR(vf)); Updates IXGBE_READ_REG(hw, IXGBE_MTA(mta_idx)); with the corresponding bit associated with mcast mac address Updates ROMPE bit which allows PF to use MTA for mcast packets. vmolr |= IXGBE_VMOLR_ROMPE; IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr); IXGBE_READ_REG(hw, IXGBE_MTA(mta_idx)); Both vf1 and vf2 have indicated to use MTA for mcast packets. When packets with dst mac 01:00:5e:00:00:01 arrives, PF checks for MTA bit associated with the mcast mac, which will be set. Since both vf1 and vf2 have indicated to use MTA, packets will be delivered to both vm1 and vm2. vm1 never intended to receive mcast packets for that mac. Let me know if this is correct? Thanks, Ravi
Re: [dpdk-dev] [ovs-dev] OvS DPDK crash when HPET timer enabled
Hi Tonghao, Thanks, your patch works fine with HPET initialization. I will look into DPDK discussion which got started with your patch. Thanks, Ravi On Mon, Apr 13, 2020 at 5:33 PM Tonghao Zhang wrote: > On Tue, Apr 14, 2020 at 7:20 AM Ilya Maximets wrote: > > > > On 4/13/20 5:27 PM, Ravi Kerur wrote: > > > On Sun, Apr 12, 2020 at 5:05 AM Tonghao Zhang < > xiangxia.m@gmail.com> > > > wrote: > > > > > >> On Sun, Apr 12, 2020 at 7:57 AM Ravi Kerur wrote: > > >>> > > >>> Hello OvS DPDK team, > > >>> > > >>> I am using OvS 2.13.90 and DPDK 19.11 and wanted to use HPET timer > > >> instead > > >>> of invariant TSC. > > >>> > > >>> Enabled CONFIG_RTE_LIBEAL_USE_HPET=y in DPDK > > >>> > > >>> Kernel has > > >>> CONFIG_HPET_TIMER=y > > >>> CONFIG_HPET_EMULATE_RTC=y > > >>> CONFIG_HPET=y > > >>> CONFIG_HPET_MMAP=y > > >>> CONFIG_HPET_MMAP_DEFAULT=y > > >>> > > >>> cat /sys/devices/system/clocksource/clocksource0/current_clocksource > > >>> tsc > > >>> # cat > /sys/devices/system/clocksource/clocksource0/available_clocksource > > >>> tsc hpet acpi_pm > > >>> > > >>> OvS crashes at > > >>> > > >>> gdb ovsdb-server /core > > >>> GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git > > >>> Copyright (C) 2018 Free Software Foundation, Inc. > > >>> License GPLv3+: GNU GPL version 3 or later < > > >> http://gnu.org/licenses/gpl.html > > >>>> > > >>> This is free software: you are free to change and redistribute it. > > >>> There is NO WARRANTY, to the extent permitted by law. Type "show > > >> copying" > > >>> and "show warranty" for details. > > >>> This GDB was configured as "x86_64-linux-gnu". > > >>> Type "show configuration" for configuration details. > > >>> For bug reporting instructions, please see: > > >>> <http://www.gnu.org/software/gdb/bugs/>. > > >>> Find the GDB manual and other documentation resources online at: > > >>> <http://www.gnu.org/software/gdb/documentation/>. > > >>> For help, type "help". > > >>> Type "apropos word" to search for commands related to "word"... > > >>> Reading symbols from ovsdb-server...done. > > >>> [New LWP 9729] > > >>> [Thread debugging using libthread_db enabled] > > >>> Using host libthread_db library > > >> "/lib/x86_64-linux-gnu/libthread_db.so.1". > > >>> Core was generated by `ovsdb-server > /usr/local/etc/openvswitch/conf.db > > >>> -vconsole:emer -vsyslog:err -vf'. > > >>> Program terminated with signal SIGSEGV, Segmentation fault. > > >>> #0 0x560fc6db8ac1 in rte_get_hpet_cycles () > > >> Hi, > > >> This is a bug on dpdk, NOT ovs. > > >> I guess that your kernel does't support getentropy which supported in > > >> 3.17 and your cpu don't support rdseed. > > >> and that cause a dpdk bug. To workaround, you change: Not tested, hope > > >> it's useful for you > > >> > > >> > > > You are correct CPU doesn't support RDSEED instruction but RDRAND is > > > supported. > > > > > > It's a RT kernel based on 4.19 + RT patches. > > > > > > Setting CONFIG_RTE_LIBEAL_USE_HPET=n which is the default,'Invariant > TSC' > > > will be used. However, I want to use HPET so should I check with DPDK > dev? > > > > Yes. This is a pure DPDK bug. There is no way to fix it from the OVS > side. > > Adding dpdk-dev in CC, moving ovs-dev to BCC to avoid cross posting. > Hi Ilya > I sent a patch to dpdk, but not applied. If applied, I feedback to this > thread. > > Actually, looking at the code in DPDK, it's really old. I'm wondering > if it > > ever worked? Looks like no-one ever tested this configuration. > > > > Best regards, Ilya Maximets. > > > > > > > > Thanks, > > > Ravi > > > > > > > > > > > >> diff --git a/lib/librte_eal/linux/eal_timer.c > > >> b/lib/librte_eal/linux/eal_timer.c > > >> index a904a8297cd2..4067e46da534
Re: [dpdk-dev] Debug crash in bucket_enqueue ()
On Thu, Oct 24, 2019 at 9:58 AM Andrew Rybchenko wrote: > Hello, > > please, see note on the following page: > https://doc.dpdk.org/guides/prog_guide/mempool_lib.html#mempool-handlers Thanks for your inputs. Note refers to '-d' for shared objects. In my case both OVS/DPDK and multi_process/simple_mp use static linked libraries. I am pretty use OVS/DPDK uses libdpdk.a which is a group of all archives. I see following from sample_mp_ovs.map file Archive member included to satisfy reference by file (symbol) /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/lib/librte_pipeline.a(rte_pipeline.o) (--whole-archive) /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/lib/librte_pipeline.a(rte_port_in_action.o) (--whole-archive) /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/lib/librte_pipeline.a(rte_table_action.o) (--whole-archive) /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/lib/librte_table.a(rte_table_lpm.o) (--whole-archive) /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/lib/librte_table.a(rte_table_lpm_ipv6.o) (--whole-archive) /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/lib/librte_table.a(rte_table_acl.o) (--whole-archive) ... Thanks. > > > Andrew. > > On 10/24/19 7:42 PM, Ravi Kerur wrote: > > DPDK team, > > > > I have a simple multi process setup with OVS/DPDK as primary and another > > process as secondary. OVS/DPDK sets up mempool and rings with MP/MC flags > > and secondary process attaches to it. I have used > > example/multi-process/simple_mp as an example. I have disabled 'ASLR' and > > made sure primary and secondary use distinct EAL lcores. > > > > test case is that for every 10/12 packets OVS/DPDK does > > rte_mempool_get() and rte_ring_enqueue() > > with information about the packets > > > > secondary process does > > rte_ring_dequeue() and rte_mempool_put() > > > > Couple of minutes into the test secondary process crashes with following > > baktrace. > > > > Any other system level settings need to be set or inputs on debugging > > bucket_enqueue? > > > > #0 0x55734160 in bucket_enqueue () > > #1 0x555edf06 in rte_mempool_ops_enqueue_bulk (mp=0x17fa9ac80, > > obj_table=0x17fac8210, n=16) at > > > /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:704 > > #2 0x555f072a in __mempool_generic_put (cache=0x17fac8100, n=1, > > obj_table=0x74e09050, mp=0x17fa9ac80) at > > > /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:1249 > > #3 rte_mempool_generic_put (cache=0x17fac8100, n=1, > > obj_table=0x74e09050, mp=0x17fa9ac80) at > > > /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:1285 > > #4 rte_mempool_put_bulk (n=1, obj_table=0x74e09050, mp=0x17fa9ac80) > at > > > /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:1308 > > #5 rte_mempool_put (obj=0x17f994300, mp=0x17fa9ac80) at > > > /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:1326 > > #6 lcore_recv (arg=0x7fffd5b3) at > /home/rkerur/simple_mp_ovs/main.c:369 > > #7 0x556df8f1 in eal_thread_loop () > > #8 0x772086db in start_thread (arg=0x74e0b700) at > > pthread_create.c:463 > > #9 0x76f3188f in clone () at > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 > > > > Thanks, > > Ravi > >
[dpdk-dev] Debug crash in bucket_enqueue ()
DPDK team, I have a simple multi process setup with OVS/DPDK as primary and another process as secondary. OVS/DPDK sets up mempool and rings with MP/MC flags and secondary process attaches to it. I have used example/multi-process/simple_mp as an example. I have disabled 'ASLR' and made sure primary and secondary use distinct EAL lcores. test case is that for every 10/12 packets OVS/DPDK does rte_mempool_get() and rte_ring_enqueue() with information about the packets secondary process does rte_ring_dequeue() and rte_mempool_put() Couple of minutes into the test secondary process crashes with following baktrace. Any other system level settings need to be set or inputs on debugging bucket_enqueue? #0 0x55734160 in bucket_enqueue () #1 0x555edf06 in rte_mempool_ops_enqueue_bulk (mp=0x17fa9ac80, obj_table=0x17fac8210, n=16) at /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:704 #2 0x555f072a in __mempool_generic_put (cache=0x17fac8100, n=1, obj_table=0x74e09050, mp=0x17fa9ac80) at /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:1249 #3 rte_mempool_generic_put (cache=0x17fac8100, n=1, obj_table=0x74e09050, mp=0x17fa9ac80) at /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:1285 #4 rte_mempool_put_bulk (n=1, obj_table=0x74e09050, mp=0x17fa9ac80) at /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:1308 #5 rte_mempool_put (obj=0x17f994300, mp=0x17fa9ac80) at /home/rkerur/dpdk-stable-18.11.2//x86_64-native-linuxapp-gcc/include/rte_mempool.h:1326 #6 lcore_recv (arg=0x7fffd5b3) at /home/rkerur/simple_mp_ovs/main.c:369 #7 0x556df8f1 in eal_thread_loop () #8 0x772086db in start_thread (arg=0x74e0b700) at pthread_create.c:463 #9 0x76f3188f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thanks, Ravi
[dpdk-dev] Documentation bug or I am doing something wrong
Hi, I have a VM and a container running inside VM. I am creating virtio/vhost as described in the following link https://dpdk.org/doc/guides/howto/virtio_user_for_container_networking.html (1st issue) Ubuntu:latest or Ubuntu:16.04 doesn't come with 'libnuma1' installed by default. If I just have following things in Dockerfile and run 'testpmd' complains about libnuma.so.1. Following section requires 'apt-get update' and 'apt-get install linbnuma1' inside the Docker file. cat <> Dockerfile FROM ubuntu:latest WORKDIR /usr/src/dpdk COPY . /usr/src/dpdk ENV PATH "$PATH:/usr/src/dpdk/x86_64-native-linuxapp-gcc/app/" EOT (2nd issue) After fixing 1st issue, if I run 'testpmd' as shown below, it fails to run with 'permission denied' for 'iopl syscall' and 'huepages'. I am running as a 'root'. I added '--privilege' to the docker command and it worked fine. My testing is 'container inside a VM' docker run -i -t -v /tmp/sock0:/var/run/usvhost \ -v /dev/hugepages:/dev/hugepages \ dpdk-app-testpmd testpmd -l 6-7 -n 4 -m 1024 --no-pci \ --vdev=virtio_user0,path=/var/run/usvhost \ --file-prefix=container \ -- -i --txqflags=0xf00 --disable-hw-vlan Let me know if it should work as it is? Thanks.
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Thu, Feb 15, 2018 at 10:27 AM, Ravi Kerur wrote: > > > On Thu, Feb 15, 2018 at 2:28 AM, Burakov, Anatoly < > anatoly.bura...@intel.com> wrote: > >> On 14-Feb-18 8:00 PM, Ravi Kerur wrote: >> >>> >>> Earlier I was focusing only on DMAR errors and I might have said 'it >>> worked' when I didn't notice them on host when dpdk was started on guest. >>> When trying to send packets out of that interface from guest I did see DMAR >>> errors. I am attaching information you requested. I have enabled >>> log-level=8 and files contain dpdk EAL/PMD logs as well. >>> >> >> Great, now we're on the same page. >> >> >>> Snippets below >>> >>> on host, DMAR fault address from dmesg >>> >>> [351576.998109] DMAR: DRHD: handling fault status reg 702 >>> [351576.998113] DMAR: [DMA Read] Request device [04:10.0] fault addr >>> 257617000 [fault reason 06] PTE Read access is not set >>> >>> on guest (dump phys_mem_layout) >>> >>> Segment 235: phys:0x25760, len:2097152, virt:0x7fce87e0, >>> socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 >>> ... >>> PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7fce87e0f4c0 >>> sw_sc_ring=0x7fce87e07380 hw_ring=0x7fce87e17600 dma_addr=0x257617600 >>> PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7fce89c67d40 >>> sw_sc_ring=0x7fce89c5fc00 hw_ring=0x7fce89c6fe80 dma_addr=0x25406fe80 >>> ... >>> >>> >> To me this looks like host (i.e. either QEMU or the PF driver) is trying >> to do DMA using guest-physical (and not host-physical). I'm not too >> well-versed in how QEMU works, but i'm pretty sure that's not supposed to >> happen. >> >> Is PF also bound to DPDK, or are you using native Linux ixgbe driver? >> > > Thanks for your help. I cannot use PF with DPDK (vfio-pci), VF interfaces > disappear after it is bound to DPDK. If there is a way to use PF and VF > with DPDK let me know I can try it out. I am not sure how to move forward > on this, Is CPU/IXGBE PF driver playing a role? Following are the versions > I have > > lscpu > Architecture: x86_64 > CPU op-mode(s):32-bit, 64-bit > Byte Order:Little Endian > CPU(s):56 > On-line CPU(s) list: 0-27 > Off-line CPU(s) list: 28-55 > Thread(s) per core:1 > Core(s) per socket:14 > Socket(s): 2 > NUMA node(s): 2 > Vendor ID: GenuineIntel > CPU family:6 > Model: 63 > Model name:Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz > Stepping: 2 > CPU MHz: 2500.610 > CPU max MHz: 3000. > CPU min MHz: 1200. > BogoMIPS: 4000.74 > Virtualization:VT-x > L1d cache: 32K > L1i cache: 32K > L2 cache: 256K > L3 cache: 35840K > NUMA node0 CPU(s): 0-13 > NUMA node1 CPU(s): 14-27 > > # ethtool -i enp4s0f0 > driver: ixgbe > version: 5.3.3 > firmware-version: 0x87b8, 1.1018.0 > bus-info: :04:00.0 > supports-statistics: yes > supports-test: yes > supports-eeprom-access: yes > supports-register-dump: yes > supports-priv-flags: yes > > Thanks, > Ravi > > > Debugging this I could co-relate doing interface link-up associated with the dpdk inside the guest causes DMAR errors on host and an additional vflr message. [ 8135.861622] DMAR: DRHD: handling fault status reg 402 [ 8135.861627] DMAR: [DMA Read] Request device [04:10.0] fault addr 1b648a000 [fault reason 06] PTE Read access is not set [ 8136.588074] ixgbe :04:00.0: Issuing VFLR with pending transactions [ 8136.588079] ixgbe :04:00.0: Issuing VFLR for VF :04:10.0 Looked at ixgbe driver code 'ixgbe_issue_vf_flr' is called from 'ixgbe_check_for_bad_vf' or 'ixgbe_io_error_detected' functions. Is it possible that dpdk pmd vf driver is missing some fixes/porting from ixgbevf driver since this issue is not seen when ixgbevf kernel driver is used? Thanks, Ravi >> -- >> Thanks, >> Anatoly >> > >
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Thu, Feb 15, 2018 at 2:28 AM, Burakov, Anatoly wrote: > On 14-Feb-18 8:00 PM, Ravi Kerur wrote: > >> >> Earlier I was focusing only on DMAR errors and I might have said 'it >> worked' when I didn't notice them on host when dpdk was started on guest. >> When trying to send packets out of that interface from guest I did see DMAR >> errors. I am attaching information you requested. I have enabled >> log-level=8 and files contain dpdk EAL/PMD logs as well. >> > > Great, now we're on the same page. > > >> Snippets below >> >> on host, DMAR fault address from dmesg >> >> [351576.998109] DMAR: DRHD: handling fault status reg 702 >> [351576.998113] DMAR: [DMA Read] Request device [04:10.0] fault addr >> 257617000 [fault reason 06] PTE Read access is not set >> >> on guest (dump phys_mem_layout) >> >> Segment 235: phys:0x25760, len:2097152, virt:0x7fce87e0, >> socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 >> ... >> PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7fce87e0f4c0 >> sw_sc_ring=0x7fce87e07380 hw_ring=0x7fce87e17600 dma_addr=0x257617600 >> PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7fce89c67d40 >> sw_sc_ring=0x7fce89c5fc00 hw_ring=0x7fce89c6fe80 dma_addr=0x25406fe80 >> ... >> >> > To me this looks like host (i.e. either QEMU or the PF driver) is trying > to do DMA using guest-physical (and not host-physical). I'm not too > well-versed in how QEMU works, but i'm pretty sure that's not supposed to > happen. > > Is PF also bound to DPDK, or are you using native Linux ixgbe driver? > Thanks for your help. I cannot use PF with DPDK (vfio-pci), VF interfaces disappear after it is bound to DPDK. If there is a way to use PF and VF with DPDK let me know I can try it out. I am not sure how to move forward on this, Is CPU/IXGBE PF driver playing a role? Following are the versions I have lscpu Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):56 On-line CPU(s) list: 0-27 Off-line CPU(s) list: 28-55 Thread(s) per core:1 Core(s) per socket:14 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family:6 Model: 63 Model name:Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz Stepping: 2 CPU MHz: 2500.610 CPU max MHz: 3000. CPU min MHz: 1200. BogoMIPS: 4000.74 Virtualization:VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 35840K NUMA node0 CPU(s): 0-13 NUMA node1 CPU(s): 14-27 # ethtool -i enp4s0f0 driver: ixgbe version: 5.3.3 firmware-version: 0x87b8, 1.1018.0 bus-info: :04:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes Thanks, Ravi > > -- > Thanks, > Anatoly >
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Tue, Feb 13, 2018 at 6:31 AM, Burakov, Anatoly wrote: > On 12-Feb-18 10:00 PM, Ravi Kerur wrote: > >> >> Let me just give you what has been tested and working/nonworking >> scenarios. Some of your questions might get answered as well. >> Test bed is very simple with 2 VF's created under IXGBE PF on >> host with one VF interface added to ovs-bridge on host and >> another VF interface given to guest. Test connectivity between >> VF's via ping. >> >> Host and guest -- Kernel 4.9 >> Host -- Qemu 2.11.50 (tried both released 2.11 and tip of the >> git (2.11.50)) >> DPDK -- 17.05.1 on host and guest >> Host and guest -- booted with GRUB intel_iommu=on (which enables >> IOMMU). Have tried with "iommu=on and intel_iommu=on" as well, >> but iommu=on is not needed when intel_iommu=on is set. >> >> Test-scenario-1: Host -- ixgbe_vf driver, Guest ixgbe_vf driver >> ping works >> Test-scenario-2: Host -- DPDK vfio-pci driver, Guest ixgbe_vf >> driver ping works >> Test-scenario-3: Host -- DPDK vfio-pci driver, Guest DPDK >> vfio-pci driver, DMAR errors seen on host, ping doesn't work >> >> >> OK, that makes it clearer, thanks. Does the third scenario work in >> other DPDK versions? >> >> >> No. Tried 16.11 same issue on guest and works fine on host. >> >> >> So now we've moved from "this worked on 16.11" to "this never worked". > > It would be good to see output of rte_dump_physmem_layout() on both host > and guest, and check which address triggers the DMAR error (i.e. if the > physical address is present in mappings for either DPDK process). > > -- > Earlier I was focusing only on DMAR errors and I might have said 'it worked' when I didn't notice them on host when dpdk was started on guest. When trying to send packets out of that interface from guest I did see DMAR errors. I am attaching information you requested. I have enabled log-level=8 and files contain dpdk EAL/PMD logs as well. Snippets below on host, DMAR fault address from dmesg [351576.998109] DMAR: DRHD: handling fault status reg 702 [351576.998113] DMAR: [DMA Read] Request device [04:10.0] fault addr 257617000 [fault reason 06] PTE Read access is not set on guest (dump phys_mem_layout) Segment 235: phys:0x25760, len:2097152, virt:0x7fce87e0, socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 ... PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7fce87e0f4c0 sw_sc_ring=0x7fce87e07380 hw_ring=0x7fce87e17600 dma_addr=0x257617600 PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7fce89c67d40 sw_sc_ring=0x7fce89c5fc00 hw_ring=0x7fce89c6fe80 dma_addr=0x25406fe80 ... Thanks, Ravi > Thanks, > Anatoly >
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Mon, Feb 12, 2018 at 2:13 AM, Burakov, Anatoly wrote: > On 10-Feb-18 5:53 PM, Ravi Kerur wrote: > > >> >> On Sat, Feb 10, 2018 at 2:58 AM, Burakov, Anatoly < >> anatoly.bura...@intel.com <mailto:anatoly.bura...@intel.com>> wrote: >> >> On 29-Jan-18 10:35 PM, Ravi Kerur wrote: >> >> Hi Burakov, >> >> When using vfio-pci on host both VF and PF interfaces works fine >> with dpdk i.e. I don't see DMAR fault messages anymore. However, >> when I attach a VF interface to a VM and start DPDK with >> vfio-pci inside VM I still see DMAR fault messages on host. Both >> host and VM are booted with 'intel-iommu=on' on GRUB. Ping from >> VM with DPDK/vfio-pci doesn't work (I think it's expected >> because of DMAR faults), however, when VF interface uses ixgbevf >> driver ping works. >> >> Following are some details >> >> /*On VM***/ >> dpdk-devbind -s >> >> Network devices using DPDK-compatible driver >> >> :00:07.0 '82599 Ethernet Controller Virtual Function' >> drv=vfio-pci unused=ixgbevf >> >> Network devices using kernel driver >> === >> :03:00.0 'Device 1041' if=eth0 drv=virtio-pci >> unused=vfio-pci *Active* >> :04:00.0 'Device 1041' if=eth1 drv=virtio-pci unused=vfio-pci >> :05:00.0 'Device 1041' if=eth2 drv=virtio-pci unused=vfio-pci >> >> Other network devices >> = >> >> >> Crypto devices using DPDK-compatible driver >> === >> >> >> Crypto devices using kernel driver >> == >> >> >> Other crypto devices >> >> >> >> >> 00:07.0 Ethernet controller: Intel Corporation 82599 Ethernet >> Controller Virtual Function (rev 01) >> Subsystem: Intel Corporation 82599 Ethernet Controller >> Virtual Function >> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- >> VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >> >TAbort- SERR- > Region 0: Memory at fda0 (64-bit, prefetchable) >> [size=16K] >> Region 3: Memory at fda04000 (64-bit, prefetchable) >> [size=16K] >> Capabilities: [70] MSI-X: Enable+ Count=3 Masked- >> Vector table: BAR=3 offset= >> PBA: BAR=3 offset=2000 >> Capabilities: [a0] Express (v1) Root Complex >> Integrated Endpoint, MSI 00 >> DevCap: MaxPayload 128 bytes, PhantFunc 0 >> ExtTag- RBE- >> DevCtl: Report errors: Correctable- Non-Fatal- >> Fatal- Unsupported- >> RlxdOrd- ExtTag- PhantFunc- AuxPwr- >> NoSnoop- >> MaxPayload 128 bytes, MaxReadReq 128 >> bytes >> DevSta: CorrErr- UncorrErr- FatalErr- >> UnsuppReq- AuxPwr- TransPend- >> Capabilities: [100 v1] Advanced Error Reporting >> UESta: DLP- SDES- TLP- FCP- CmpltTO- >> CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- >> CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UESvrt: DLP- SDES- TLP- FCP- CmpltTO- >> CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> CESta: RxErr- BadTLP- BadDLLP- Rollover- >> Timeout- NonFatalErr- >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- >> Timeout- NonFatalErr- >> AERCap: First Error Pointer: 00, GenCap- >> CGenEn- ChkCap- ChkEn- >> Kernel driver in use: vfio-pci >> Kernel modules: ixgbevf >> >> /***on
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Sat, Feb 10, 2018 at 2:58 AM, Burakov, Anatoly wrote: > On 29-Jan-18 10:35 PM, Ravi Kerur wrote: > >> Hi Burakov, >> >> When using vfio-pci on host both VF and PF interfaces works fine with >> dpdk i.e. I don't see DMAR fault messages anymore. However, when I attach a >> VF interface to a VM and start DPDK with vfio-pci inside VM I still see >> DMAR fault messages on host. Both host and VM are booted with >> 'intel-iommu=on' on GRUB. Ping from VM with DPDK/vfio-pci doesn't work (I >> think it's expected because of DMAR faults), however, when VF interface >> uses ixgbevf driver ping works. >> >> Following are some details >> >> /*On VM***/ >> dpdk-devbind -s >> >> Network devices using DPDK-compatible driver >> >> :00:07.0 '82599 Ethernet Controller Virtual Function' drv=vfio-pci >> unused=ixgbevf >> >> Network devices using kernel driver >> === >> :03:00.0 'Device 1041' if=eth0 drv=virtio-pci unused=vfio-pci *Active* >> :04:00.0 'Device 1041' if=eth1 drv=virtio-pci unused=vfio-pci >> :05:00.0 'Device 1041' if=eth2 drv=virtio-pci unused=vfio-pci >> >> Other network devices >> = >> >> >> Crypto devices using DPDK-compatible driver >> === >> >> >> Crypto devices using kernel driver >> == >> >> >> Other crypto devices >> >> >> >> >> 00:07.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller >> Virtual Function (rev 01) >> Subsystem: Intel Corporation 82599 Ethernet Controller Virtual >> Function >> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >> SERR- > Region 0: Memory at fda0 (64-bit, prefetchable) [size=16K] >> Region 3: Memory at fda04000 (64-bit, prefetchable) [size=16K] >> Capabilities: [70] MSI-X: Enable+ Count=3 Masked- >> Vector table: BAR=3 offset= >> PBA: BAR=3 offset=2000 >> Capabilities: [a0] Express (v1) Root Complex Integrated >> Endpoint, MSI 00 >> DevCap: MaxPayload 128 bytes, PhantFunc 0 >> ExtTag- RBE- >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- >> Unsupported- >> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >> MaxPayload 128 bytes, MaxReadReq 128 bytes >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- >> TransPend- >> Capabilities: [100 v1] Advanced Error Reporting >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- >> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- >> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UESvrt: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- >> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- >> NonFatalErr- >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- >> NonFatalErr- >> AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- >> ChkEn- >> Kernel driver in use: vfio-pci >> Kernel modules: ixgbevf >> >> /***on Host*/ >> dmesg | grep DMAR >> ... >> [ 978.268143] DMAR: DRHD: handling fault status reg 2 >> [ 978.268147] DMAR: [DMA Read] *Request device [04:10.0]* fault addr >> 33a128000 [fault reason 06] PTE Read access is not set >> [ 1286.677726] DMAR: DRHD: handling fault status reg 102 >> [ 1286.677730] DMAR: [DMA Read] Request device [04:10.0] fault addr >> fb663000 [fault reason 06] PTE Read access is not set >> [ 1676.436145] DMAR: DRHD: handling fault status reg 202 >> [ 1676.436149] DMAR: [DMA Read] Request device [04:10.0] fault addr >> 33a128000 [fault reason 06] PTE Read access is not set >> [ 1734.433649] DMAR: DRHD: handling fault status reg 302 >> [ 1734.433652] DMAR: [DMA Read] Request device [04:10.0] fault addr >> 33a128000 [fault reason 06] PTE Read access is not set >> [ 2324.428938] DMAR
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Thu, Feb 8, 2018 at 3:20 AM, Burakov, Anatoly wrote: > On 06-Feb-18 5:55 PM, Ravi Kerur wrote: > >> >> Hi Anatoly, >> >> I am actually confused with the state of vIOMMU + DPDK. Can you please >> help me clarify? >> >> I tested following DPDK versions >> >> (1) DPDK 17.11, exhibits the issue (IOMMU width as reported by RedHat and >> solution is to prevent using the patch) >> (2) DPDK 17.05.02 (stable release) using 'testpmd' I was able to bind a >> device in VM with VFIO driver and no DMAR error message on host >> (3) DPDK 16.11.02 (stable release) using 'testpmd' I was able to bind a >> device in VM with VFIO driver and no DMAR error message on host >> >> Clearly issue seen in 17.11 without the patch you mentioned is a >> regression or the issue was masked in earlier DPDK version? I did not test >> traffic with any DPDK version because I wanted to first get DMAR errors on >> host gone. >> >> Our application 'v1' is integrated with DPDK 16.11 and 'v2' is integrated >> with DPDK 17.05.01. In both 'v1' and 'v2' cases I don't see IOMMU width >> error messages on VM, however, DMAR error messages are seen host. I am not >> able to relate what causes DMAR error messages on host? >> >> >> Thanks. >> >> > Hi Ravi, > > vIOMMU support is out of our hands, really - we can only make use of > hardware (or emulation of it) that is available. 39-bit wide address *can* > work, you just have to be lucky and get PA addresses that would fit into 39 > bits (so under 512G limit), because we set up IOVA addresses to be 1:1 to > physical addresses. We could, in principle, set up IOVA addresses to go > from zero instead of them being a 1:1 mapping to physical addresses, but > that would introduce need to translate addresses between IOVA and physical > in some cases (e.g. KNI). > > I'm not aware of any changes between 16.11 and 17.11 (and indeed 18.02) > that would make or break support for 39-bit wide PA addresses for IOMMU. It > is possible that VF/PF drivers do something differently which results in > DMAR errors showing up sooner rather than later, but as far as VFIO support > itself is concerned, there were no major changes in those releases. > > Hi Anatoly, Thank you for your explanation. I would like to ask one more thing as I need to get v-iommu+ dpdk working in VM. Can you please tell me what determines 'Host Address Width", I know my question has nothing to do with dpdk and this is a dpdk list, but if you have any information please share it? I googled and found couple of ways to influence 'Host Address Width = 46' in guest as well (since dpdk + iommu works fine on host and DMAR on host reports address width as 46). (1) Qemu has CPU param 'host-phys-bits' boolean, when set to true copies it from host (2) Qemu has 'phys-bits' integer, when set to '46' should influence guest Using above options when instantiating a VM doesn't help, Guest VM still ends up with 'Host address width = 39'. (3) There is another Qemu option 'x-aw-bits' which is for VT-d which can be set to '39' or '48'. This doesn't help either. Thanks. -- > Thanks, > Anatoly >
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Mon, Feb 5, 2018 at 2:01 AM, Burakov, Anatoly wrote: > On 02-Feb-18 8:51 PM, Ravi Kerur wrote: > >> >> >> On Fri, Feb 2, 2018 at 12:21 PM, Ravi Kerur > rke...@gmail.com>> wrote: >> >> >> >> On Fri, Feb 2, 2018 at 2:28 AM, Burakov, Anatoly >> mailto:anatoly.bura...@intel.com>> wrote: >> >> On 01-Feb-18 7:26 PM, Ravi Kerur wrote: >> >> >> >> On Thu, Feb 1, 2018 at 2:10 AM, Burakov, Anatoly >> > <mailto:anatoly.bura...@intel.com> >> <mailto:anatoly.bura...@intel.com >> >> <mailto:anatoly.bura...@intel.com>>> wrote: >> >> On 31-Jan-18 9:51 PM, Ravi Kerur wrote: >> >> >> Hi Anatoly, >> >> Thanks. I am following wiki link below which uses >> vIOMMU with >> DPDK as a use-case and instantiate VM as specified >> with Q35 >> chipset in Qemu. >> >> https://wiki.qemu.org/Features/VT-d >> <https://wiki.qemu.org/Features/VT-d> >> <https://wiki.qemu.org/Features/VT-d >> <https://wiki.qemu.org/Features/VT-d>> >> >> Qemu-version is 2.11 >> Host kernel 4.9 >> Guest kernel 4.4 >> >> I can only guess that guest kernel needs an upgrade >> in my setup >> to work correctly, if versions on my setup rings a >> bell on not >> having support kindly let me know. >> >> When 'modprobe vfio enable_unsafe_noiommu_node=Y' >> is executed on >> guest I get following error >> ... >> vfio: unknown parameter >> 'enable_unsafe_noiommu_node' ignored >> ... >> >> in guest. >> >> Thanks. >> >> >> AFAIK kernel 4.4 should have noiommu mode - it was >> introduced in >> 3.1x days. However, in order for that to work, kernel >> also has to be >> built with this mode enabled. My guess is, whoever is >> the supplier >> of your kernel, did not do that. You should >> double-check the kernel >> configuration of your distribution. >> >> However, if you have vIOMMU in QEMU, you shouldn't need >> noiommu mode >> - "regular" vfio should work fine. noiommu mode should >> only be >> needed if you know you don't have IOMMU enabled in your >> kernel, and >> even if you can't enable it, you can still use igb_uio. >> >> Hi Anatoly, >> >> Do you suggest I take this discussion to kvm/qemu mailing >> list as I am not sure which component has the issue? I check >> dmesg for BIOS physical memory map and address reported as >> fault by DMAR is reported by BIOS as usable on both host and >> vm. >> >> [ 4539.597737] DMAR: [DMA Read] Request device [04:10.0] >> fault addr *33a128000 *[fault reason 06] PTE Read access is >> not set >> >> dmesg | grep BIOS >> [0.00] e820: BIOS-provided physical RAM map: >> [0.00] BIOS-e820: [mem >> 0x-0x0009afff] usable >> [0.00] BIOS-e820: [mem >> 0x0009b000-0x0009] reserved >> [0.00] BIOS-e820: [mem >> 0x000e-0x000f] reserved >> [0.00] BIOS-e820: [mem >> 0x0010-0x7938afff] usable >> [0.00] BIOS-e820: [mem >> 0x7938b000-0x7994bfff] reserved >> [0.00] BIOS-e820: [mem >> 0x7994c000-0x7999cfff] ACPI data >> [0.00] BIOS-e820: [mem >> 0x7999d000-0x79f7dfff] ACPI NVS >> [0.00] BIOS-e820: [mem >>
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Fri, Feb 2, 2018 at 12:21 PM, Ravi Kerur wrote: > > > On Fri, Feb 2, 2018 at 2:28 AM, Burakov, Anatoly < > anatoly.bura...@intel.com> wrote: > >> On 01-Feb-18 7:26 PM, Ravi Kerur wrote: >> >>> >>> >>> On Thu, Feb 1, 2018 at 2:10 AM, Burakov, Anatoly < >>> anatoly.bura...@intel.com <mailto:anatoly.bura...@intel.com>> wrote: >>> >>> On 31-Jan-18 9:51 PM, Ravi Kerur wrote: >>> >>> >>> Hi Anatoly, >>> >>> Thanks. I am following wiki link below which uses vIOMMU with >>> DPDK as a use-case and instantiate VM as specified with Q35 >>> chipset in Qemu. >>> >>> https://wiki.qemu.org/Features/VT-d >>> <https://wiki.qemu.org/Features/VT-d> >>> >>> Qemu-version is 2.11 >>> Host kernel 4.9 >>> Guest kernel 4.4 >>> >>> I can only guess that guest kernel needs an upgrade in my setup >>> to work correctly, if versions on my setup rings a bell on not >>> having support kindly let me know. >>> >>> When 'modprobe vfio enable_unsafe_noiommu_node=Y' is executed on >>> guest I get following error >>> ... >>> vfio: unknown parameter 'enable_unsafe_noiommu_node' ignored >>> ... >>> >>> in guest. >>> >>> Thanks. >>> >>> >>> AFAIK kernel 4.4 should have noiommu mode - it was introduced in >>> 3.1x days. However, in order for that to work, kernel also has to be >>> built with this mode enabled. My guess is, whoever is the supplier >>> of your kernel, did not do that. You should double-check the kernel >>> configuration of your distribution. >>> >>> However, if you have vIOMMU in QEMU, you shouldn't need noiommu mode >>> - "regular" vfio should work fine. noiommu mode should only be >>> needed if you know you don't have IOMMU enabled in your kernel, and >>> even if you can't enable it, you can still use igb_uio. >>> >>> Hi Anatoly, >>> >>> Do you suggest I take this discussion to kvm/qemu mailing list as I am >>> not sure which component has the issue? I check dmesg for BIOS physical >>> memory map and address reported as fault by DMAR is reported by BIOS as >>> usable on both host and vm. >>> >>> [ 4539.597737] DMAR: [DMA Read] Request device [04:10.0] fault addr >>> *33a128000 *[fault reason 06] PTE Read access is not set >>> >>> dmesg | grep BIOS >>> [0.00] e820: BIOS-provided physical RAM map: >>> [0.00] BIOS-e820: [mem 0x-0x0009afff] >>> usable >>> [0.00] BIOS-e820: [mem 0x0009b000-0x0009] >>> reserved >>> [0.00] BIOS-e820: [mem 0x000e-0x000f] >>> reserved >>> [0.00] BIOS-e820: [mem 0x0010-0x7938afff] >>> usable >>> [0.00] BIOS-e820: [mem 0x7938b000-0x7994bfff] >>> reserved >>> [0.00] BIOS-e820: [mem 0x7994c000-0x7999cfff] >>> ACPI data >>> [0.00] BIOS-e820: [mem 0x7999d000-0x79f7dfff] >>> ACPI NVS >>> [0.00] BIOS-e820: [mem 0x79f7e000-0x7bd37fff] >>> reserved >>> [0.00] BIOS-e820: [mem 0x7bd38000-0x7bd38fff] >>> usable >>> [0.00] BIOS-e820: [mem 0x7bd39000-0x7bdbefff] >>> reserved >>> [0.00] BIOS-e820: [mem 0x7bdbf000-0x7bff] >>> usable >>> [0.00] BIOS-e820: [mem 0x7c00-0x8fff] >>> reserved >>> [0.00] BIOS-e820: [mem 0xfed1c000-0xfed44fff] >>> reserved >>> [0.00] BIOS-e820: [mem 0xff00-0x] >>> reserved >>> [*0.00] BIOS-e820: [mem 0x0001-0x00407fff] >>> usable* >>> * >>> * >>> Kindly let me know your inputs. >>> >>> Thanks. >>> >>> >>> -- Thanks, >>> Anatoly >>> >>> >>> >> The "PTE Read not set" error usually indicates that you are trying to use >> a non-IOMMU method when you have IOMMU enabled (i.e. t
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Fri, Feb 2, 2018 at 2:28 AM, Burakov, Anatoly wrote: > On 01-Feb-18 7:26 PM, Ravi Kerur wrote: > >> >> >> On Thu, Feb 1, 2018 at 2:10 AM, Burakov, Anatoly < >> anatoly.bura...@intel.com <mailto:anatoly.bura...@intel.com>> wrote: >> >> On 31-Jan-18 9:51 PM, Ravi Kerur wrote: >> >> >> Hi Anatoly, >> >> Thanks. I am following wiki link below which uses vIOMMU with >> DPDK as a use-case and instantiate VM as specified with Q35 >> chipset in Qemu. >> >> https://wiki.qemu.org/Features/VT-d >> <https://wiki.qemu.org/Features/VT-d> >> >> Qemu-version is 2.11 >> Host kernel 4.9 >> Guest kernel 4.4 >> >> I can only guess that guest kernel needs an upgrade in my setup >> to work correctly, if versions on my setup rings a bell on not >> having support kindly let me know. >> >> When 'modprobe vfio enable_unsafe_noiommu_node=Y' is executed on >> guest I get following error >> ... >> vfio: unknown parameter 'enable_unsafe_noiommu_node' ignored >> ... >> >> in guest. >> >> Thanks. >> >> >> AFAIK kernel 4.4 should have noiommu mode - it was introduced in >> 3.1x days. However, in order for that to work, kernel also has to be >> built with this mode enabled. My guess is, whoever is the supplier >> of your kernel, did not do that. You should double-check the kernel >> configuration of your distribution. >> >> However, if you have vIOMMU in QEMU, you shouldn't need noiommu mode >> - "regular" vfio should work fine. noiommu mode should only be >> needed if you know you don't have IOMMU enabled in your kernel, and >> even if you can't enable it, you can still use igb_uio. >> >> Hi Anatoly, >> >> Do you suggest I take this discussion to kvm/qemu mailing list as I am >> not sure which component has the issue? I check dmesg for BIOS physical >> memory map and address reported as fault by DMAR is reported by BIOS as >> usable on both host and vm. >> >> [ 4539.597737] DMAR: [DMA Read] Request device [04:10.0] fault addr >> *33a128000 *[fault reason 06] PTE Read access is not set >> >> dmesg | grep BIOS >> [0.00] e820: BIOS-provided physical RAM map: >> [0.00] BIOS-e820: [mem 0x-0x0009afff] >> usable >> [0.00] BIOS-e820: [mem 0x0009b000-0x0009] >> reserved >> [0.00] BIOS-e820: [mem 0x000e-0x000f] >> reserved >> [0.00] BIOS-e820: [mem 0x0010-0x7938afff] >> usable >> [0.00] BIOS-e820: [mem 0x7938b000-0x7994bfff] >> reserved >> [0.00] BIOS-e820: [mem 0x7994c000-0x7999cfff] >> ACPI data >> [0.00] BIOS-e820: [mem 0x7999d000-0x79f7dfff] >> ACPI NVS >> [0.00] BIOS-e820: [mem 0x79f7e000-0x7bd37fff] >> reserved >> [0.00] BIOS-e820: [mem 0x7bd38000-0x7bd38fff] >> usable >> [0.00] BIOS-e820: [mem 0x7bd39000-0x7bdbefff] >> reserved >> [0.00] BIOS-e820: [mem 0x7bdbf000-0x7bff] >> usable >> [0.00] BIOS-e820: [mem 0x7c00-0x8fff] >> reserved >> [0.00] BIOS-e820: [mem 0xfed1c000-0xfed44fff] >> reserved >> [0.00] BIOS-e820: [mem 0xff00-0x] >> reserved >> [*0.00] BIOS-e820: [mem 0x0001-0x00407fff] >> usable* >> * >> * >> Kindly let me know your inputs. >> >> Thanks. >> >> >> -- Thanks, >> Anatoly >> >> >> > The "PTE Read not set" error usually indicates that you are trying to use > a non-IOMMU method when you have IOMMU enabled (i.e. trying to use igb_uio > when IOMMU is on). That, to me, indicates that you do have IOMMU emulation > enabled. > > I would go about it this way. > > First, i'd ensure that your VM has IOMMU emulation enabled and working. > You have mentioned that your QEMU version should have IOMMU emulation, so > let's assume that's the case. > > I am not sure of the exact command-line needed to activate the vIOMMU > emulation, but assuming your VM emulates an Intel processor, your kernel > co
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Thu, Feb 1, 2018 at 2:10 AM, Burakov, Anatoly wrote: > On 31-Jan-18 9:51 PM, Ravi Kerur wrote: > >> >> Hi Anatoly, >> >> Thanks. I am following wiki link below which uses vIOMMU with DPDK as a >> use-case and instantiate VM as specified with Q35 chipset in Qemu. >> >> https://wiki.qemu.org/Features/VT-d >> >> Qemu-version is 2.11 >> Host kernel 4.9 >> Guest kernel 4.4 >> >> I can only guess that guest kernel needs an upgrade in my setup to work >> correctly, if versions on my setup rings a bell on not having support >> kindly let me know. >> >> When 'modprobe vfio enable_unsafe_noiommu_node=Y' is executed on guest I >> get following error >> ... >> vfio: unknown parameter 'enable_unsafe_noiommu_node' ignored >> ... >> >> in guest. >> >> Thanks. >> > > AFAIK kernel 4.4 should have noiommu mode - it was introduced in 3.1x days. > However, in order for that to work, kernel also has to be built with this > mode enabled. My guess is, whoever is the supplier of your kernel, did not > do that. You should double-check the kernel configuration of your > distribution. > > However, if you have vIOMMU in QEMU, you shouldn't need noiommu mode - > "regular" vfio should work fine. noiommu mode should only be needed if you > know you don't have IOMMU enabled in your kernel, and even if you can't > enable it, you can still use igb_uio. > > Hi Anatoly, Do you suggest I take this discussion to kvm/qemu mailing list as I am not sure which component has the issue? I check dmesg for BIOS physical memory map and address reported as fault by DMAR is reported by BIOS as usable on both host and vm. [ 4539.597737] DMAR: [DMA Read] Request device [04:10.0] fault addr *33a128000 *[fault reason 06] PTE Read access is not set dmesg | grep BIOS [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009afff] usable [0.00] BIOS-e820: [mem 0x0009b000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x7938afff] usable [0.00] BIOS-e820: [mem 0x7938b000-0x7994bfff] reserved [0.00] BIOS-e820: [mem 0x7994c000-0x7999cfff] ACPI data [0.00] BIOS-e820: [mem 0x7999d000-0x79f7dfff] ACPI NVS [0.00] BIOS-e820: [mem 0x79f7e000-0x7bd37fff] reserved [0.00] BIOS-e820: [mem 0x7bd38000-0x7bd38fff] usable [0.00] BIOS-e820: [mem 0x7bd39000-0x7bdbefff] reserved [0.00] BIOS-e820: [mem 0x7bdbf000-0x7bff] usable [0.00] BIOS-e820: [mem 0x7c00-0x8fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed44fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [*0.00] BIOS-e820: [mem 0x0001-0x00407fff] usable* Kindly let me know your inputs. Thanks. -- > Thanks, > Anatoly >
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
On Wed, Jan 31, 2018 at 1:59 AM, Burakov, Anatoly wrote: > On 29-Jan-18 10:35 PM, Ravi Kerur wrote: > >> Hi Burakov, >> >> When using vfio-pci on host both VF and PF interfaces works fine with >> dpdk i.e. I don't see DMAR fault messages anymore. However, when I attach a >> VF interface to a VM and start DPDK with vfio-pci inside VM I still see >> DMAR fault messages on host. Both host and VM are booted with >> 'intel-iommu=on' on GRUB. Ping from VM with DPDK/vfio-pci doesn't work (I >> think it's expected because of DMAR faults), however, when VF interface >> uses ixgbevf driver ping works. >> >> Following are some details >> >> /*On VM***/ >> dpdk-devbind -s >> >> Network devices using DPDK-compatible driver >> >> :00:07.0 '82599 Ethernet Controller Virtual Function' drv=vfio-pci >> unused=ixgbevf >> >> Network devices using kernel driver >> === >> :03:00.0 'Device 1041' if=eth0 drv=virtio-pci unused=vfio-pci *Active* >> :04:00.0 'Device 1041' if=eth1 drv=virtio-pci unused=vfio-pci >> :05:00.0 'Device 1041' if=eth2 drv=virtio-pci unused=vfio-pci >> >> Other network devices >> = >> >> >> Crypto devices using DPDK-compatible driver >> === >> >> >> Crypto devices using kernel driver >> == >> >> >> Other crypto devices >> >> >> >> >> 00:07.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller >> Virtual Function (rev 01) >> Subsystem: Intel Corporation 82599 Ethernet Controller Virtual >> Function >> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >> SERR- > Region 0: Memory at fda0 (64-bit, prefetchable) [size=16K] >> Region 3: Memory at fda04000 (64-bit, prefetchable) [size=16K] >> Capabilities: [70] MSI-X: Enable+ Count=3 Masked- >> Vector table: BAR=3 offset= >> PBA: BAR=3 offset=2000 >> Capabilities: [a0] Express (v1) Root Complex Integrated >> Endpoint, MSI 00 >> DevCap: MaxPayload 128 bytes, PhantFunc 0 >> ExtTag- RBE- >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- >> Unsupported- >> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >> MaxPayload 128 bytes, MaxReadReq 128 bytes >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- >> TransPend- >> Capabilities: [100 v1] Advanced Error Reporting >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- >> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- >> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UESvrt: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- >> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- >> NonFatalErr- >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- >> NonFatalErr- >> AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- >> ChkEn- >> Kernel driver in use: vfio-pci >> Kernel modules: ixgbevf >> >> /***on Host*/ >> dmesg | grep DMAR >> ... >> [ 978.268143] DMAR: DRHD: handling fault status reg 2 >> [ 978.268147] DMAR: [DMA Read] *Request device [04:10.0]* fault addr >> 33a128000 [fault reason 06] PTE Read access is not set >> [ 1286.677726] DMAR: DRHD: handling fault status reg 102 >> [ 1286.677730] DMAR: [DMA Read] Request device [04:10.0] fault addr >> fb663000 [fault reason 06] PTE Read access is not set >> [ 1676.436145] DMAR: DRHD: handling fault status reg 202 >> [ 1676.436149] DMAR: [DMA Read] Request device [04:10.0] fault addr >> 33a128000 [fault reason 06] PTE Read access is not set >> [ 1734.433649] DMAR: DRHD: handling fault status reg 302 >> [ 1734.433652] DMAR: [DMA Read] Request device [04:10.0] fault addr >> 33a128000 [fault reason 06] PTE Read access is not set >> [ 2324.428938] DMAR: DRHD: h
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
Hi Burakov, When using vfio-pci on host both VF and PF interfaces works fine with dpdk i.e. I don't see DMAR fault messages anymore. However, when I attach a VF interface to a VM and start DPDK with vfio-pci inside VM I still see DMAR fault messages on host. Both host and VM are booted with 'intel-iommu=on' on GRUB. Ping from VM with DPDK/vfio-pci doesn't work (I think it's expected because of DMAR faults), however, when VF interface uses ixgbevf driver ping works. Following are some details /*On VM***/ dpdk-devbind -s Network devices using DPDK-compatible driver :00:07.0 '82599 Ethernet Controller Virtual Function' drv=vfio-pci unused=ixgbevf Network devices using kernel driver === :03:00.0 'Device 1041' if=eth0 drv=virtio-pci unused=vfio-pci *Active* :04:00.0 'Device 1041' if=eth1 drv=virtio-pci unused=vfio-pci :05:00.0 'Device 1041' if=eth2 drv=virtio-pci unused=vfio-pci Other network devices = Crypto devices using DPDK-compatible driver === Crypto devices using kernel driver == Other crypto devices 00:07.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) Subsystem: Intel Corporation 82599 Ethernet Controller Virtual Function Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- wrote: > On 24-Jan-18 7:13 PM, Ravi Kerur wrote: > >> Hi Burakov, Thank you. I will try with vfio-pci driver. I am assuming it >> will work for both PF and VF interfaces since I am using both in my setup? >> >> Thanks. >> > > Yes, it should work for both PF and VF devices. > > >> On Wed, Jan 24, 2018 at 2:31 AM, Burakov, Anatoly < >> anatoly.bura...@intel.com <mailto:anatoly.bura...@intel.com>> wrote: >> >> On 23-Jan-18 5:25 PM, Ravi Kerur wrote: >> >> Hi, >> >> I am running into an issue when DPDK is started with iommu on >> via GRUB >> command. Problem is not seen with regular kernel driver, error >> messages >> show when DPDK is started and happens for both PF and VF >> interfaces. >> >> I am using DPDK 17.05 so the patch proposed in the following link >> is >> available >> http://dpdk.org/ml/archives/dev/2017-February/057048.html >> <http://dpdk.org/ml/archives/dev/2017-February/057048.html> >> >> Workaround is to use "iommu=pt" but I want iommu enabled in my >> setup. I >> checked BIOS for reserved memory(DMA RMRR for IXGBE) didn't get >> any details >> on it. >> >> Kindly let me know how to resolve this issue. >> >> Following are the details >> >> (1) Linux kernel 4.9 >> (2) DPDK 17.05 >> >> (3) IXGBE details >> ethtool -i enp4s0f0 (PF driver) >> driver: ixgbe >> version: 5.3.3 >> firmware-version: 0x87b8, 1.1018.0 >> bus-info: :04:00.0 >> supports-statistics: yes >> supports-test: yes >> supports-eeprom-access: yes >> supports-register-dump: yes >> supports-priv-flags: yes >> >> ethtool -i enp4s16f2 (VF driver) >> driver: ixgbevf >> version: 4.3.2 >> firmware-version: >> bus-info: :04:10.2 >> supports-statistics: yes >> supports-test: yes >> supports-eeprom-access: no >> supports-register-dump: yes >> supports-priv-flags: no >> >> Bus info Device Class Description >> = >> pci@:01:00.0 ens11f0 network82599ES 10-Gigabit >> SFI/SFP+ >> Network Connection >> pci@:01:00.1 ens11f1 network82599ES 10-Gigabit >> SFI/SFP+ >> Network Connection >> pci@:04:00.0 enp4s0f0 network82599ES 10-Gigabit >> SFI/SFP+ >> Network Connection >> pci@:04:00.1 enp4s0f1 network82599ES 10-Gigabit >> SFI/SFP+ >> Network Connection >> pci@:04:10.0 enp4s16 ne
Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
Hi Burakov, Thank you. I will try with vfio-pci driver. I am assuming it will work for both PF and VF interfaces since I am using both in my setup? Thanks. On Wed, Jan 24, 2018 at 2:31 AM, Burakov, Anatoly wrote: > On 23-Jan-18 5:25 PM, Ravi Kerur wrote: > >> Hi, >> >> I am running into an issue when DPDK is started with iommu on via GRUB >> command. Problem is not seen with regular kernel driver, error messages >> show when DPDK is started and happens for both PF and VF interfaces. >> >> I am using DPDK 17.05 so the patch proposed in the following link is >> available >> http://dpdk.org/ml/archives/dev/2017-February/057048.html >> >> Workaround is to use "iommu=pt" but I want iommu enabled in my setup. I >> checked BIOS for reserved memory(DMA RMRR for IXGBE) didn't get any >> details >> on it. >> >> Kindly let me know how to resolve this issue. >> >> Following are the details >> >> (1) Linux kernel 4.9 >> (2) DPDK 17.05 >> >> (3) IXGBE details >> ethtool -i enp4s0f0 (PF driver) >> driver: ixgbe >> version: 5.3.3 >> firmware-version: 0x87b8, 1.1018.0 >> bus-info: :04:00.0 >> supports-statistics: yes >> supports-test: yes >> supports-eeprom-access: yes >> supports-register-dump: yes >> supports-priv-flags: yes >> >> ethtool -i enp4s16f2 (VF driver) >> driver: ixgbevf >> version: 4.3.2 >> firmware-version: >> bus-info: :04:10.2 >> supports-statistics: yes >> supports-test: yes >> supports-eeprom-access: no >> supports-register-dump: yes >> supports-priv-flags: no >> >> Bus info Device Class Description >> = >> pci@:01:00.0 ens11f0 network82599ES 10-Gigabit SFI/SFP+ >> Network Connection >> pci@:01:00.1 ens11f1 network82599ES 10-Gigabit SFI/SFP+ >> Network Connection >> pci@:04:00.0 enp4s0f0 network82599ES 10-Gigabit SFI/SFP+ >> Network Connection >> pci@:04:00.1 enp4s0f1 network82599ES 10-Gigabit SFI/SFP+ >> Network Connection >> pci@:04:10.0 enp4s16 networkIllegal Vendor ID >> pci@:04:10.2 enp4s16f2networkIllegal Vendor ID >> >> (4) DPDK bind interfaces >> >> # dpdk-devbind -s >> >> Network devices using DPDK-compatible driver >> >> :01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' >> drv=igb_uio unused=vfio-pci >> :04:10.2 '82599 Ethernet Controller Virtual Function 10ed' drv=igb_uio >> unused=vfio-pci >> >> Network devices using kernel driver >> === >> :01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' >> if=ens11f1 drv=ixgbe unused=igb_uio,vfio-pci >> :04:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' >> if=enp4s0f0 drv=ixgbe unused=igb_uio,vfio-pci >> :04:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' >> if=enp4s0f1 drv=ixgbe unused=igb_uio,vfio-pci >> :04:10.0 '82599 Ethernet Controller Virtual Function 10ed' if=enp4s16 >> drv=ixgbevf unused=igb_uio,vfio-pci >> :06:00.0 'I210 Gigabit Network Connection 1533' if=eno1 drv=igb >> unused=igb_uio,vfio-pci *Active* >> >> Other Network devices >> = >> >> >> ... >> >> (5) Kernel dmesg >> >> # dmesg | grep -e DMAR >> [0.00] ACPI: DMAR 0x7999BAD0 E0 (v01 ALASKA A M I >> 0001 INTL 20091013) >> [0.00] DMAR: IOMMU enabled >> [0.518747] DMAR: Host address width 46 >> [0.526616] DMAR: DRHD base: 0x00fbffc000 flags: 0x0 >> [0.537447] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap >> d2078c106f0466 ecap f020df >> [0.553620] DMAR: DRHD base: 0x00c7ffc000 flags: 0x1 >> [0.564445] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap >> d2078c106f0466 ecap f020df >> [0.580611] DMAR: RMRR base: 0x007bbc6000 end: 0x007bbd4fff >> [0.593344] DMAR: ATSR flags: 0x0 >> [0.600178] DMAR: RHSA base: 0x00c7ffc000 proximity domain: 0x0 >> [0.612905] DMAR: RHSA base: 0x00fbffc000 proximity domain: 0x1 >> [0.625632] DMAR-IR: IOAPIC id 3 under DRHD base 0xfbffc000 IOMMU 0 >> [0.638522] DMAR-IR: IOAPIC id 1 under DRHD base 0xc7ffc000 IOMMU 1 >> [0.651426] DMAR-IR: IOAPIC id 2 under
[dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
Hi, I am running into an issue when DPDK is started with iommu on via GRUB command. Problem is not seen with regular kernel driver, error messages show when DPDK is started and happens for both PF and VF interfaces. I am using DPDK 17.05 so the patch proposed in the following link is available http://dpdk.org/ml/archives/dev/2017-February/057048.html Workaround is to use "iommu=pt" but I want iommu enabled in my setup. I checked BIOS for reserved memory(DMA RMRR for IXGBE) didn't get any details on it. Kindly let me know how to resolve this issue. Following are the details (1) Linux kernel 4.9 (2) DPDK 17.05 (3) IXGBE details ethtool -i enp4s0f0 (PF driver) driver: ixgbe version: 5.3.3 firmware-version: 0x87b8, 1.1018.0 bus-info: :04:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes ethtool -i enp4s16f2 (VF driver) driver: ixgbevf version: 4.3.2 firmware-version: bus-info: :04:10.2 supports-statistics: yes supports-test: yes supports-eeprom-access: no supports-register-dump: yes supports-priv-flags: no Bus info Device Class Description = pci@:01:00.0 ens11f0 network82599ES 10-Gigabit SFI/SFP+ Network Connection pci@:01:00.1 ens11f1 network82599ES 10-Gigabit SFI/SFP+ Network Connection pci@:04:00.0 enp4s0f0 network82599ES 10-Gigabit SFI/SFP+ Network Connection pci@:04:00.1 enp4s0f1 network82599ES 10-Gigabit SFI/SFP+ Network Connection pci@:04:10.0 enp4s16 networkIllegal Vendor ID pci@:04:10.2 enp4s16f2networkIllegal Vendor ID (4) DPDK bind interfaces # dpdk-devbind -s Network devices using DPDK-compatible driver :01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' drv=igb_uio unused=vfio-pci :04:10.2 '82599 Ethernet Controller Virtual Function 10ed' drv=igb_uio unused=vfio-pci Network devices using kernel driver === :01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=ens11f1 drv=ixgbe unused=igb_uio,vfio-pci :04:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=enp4s0f0 drv=ixgbe unused=igb_uio,vfio-pci :04:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' if=enp4s0f1 drv=ixgbe unused=igb_uio,vfio-pci :04:10.0 '82599 Ethernet Controller Virtual Function 10ed' if=enp4s16 drv=ixgbevf unused=igb_uio,vfio-pci :06:00.0 'I210 Gigabit Network Connection 1533' if=eno1 drv=igb unused=igb_uio,vfio-pci *Active* Other Network devices = ... (5) Kernel dmesg # dmesg | grep -e DMAR [0.00] ACPI: DMAR 0x7999BAD0 E0 (v01 ALASKA A M I 0001 INTL 20091013) [0.00] DMAR: IOMMU enabled [0.518747] DMAR: Host address width 46 [0.526616] DMAR: DRHD base: 0x00fbffc000 flags: 0x0 [0.537447] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap d2078c106f0466 ecap f020df [0.553620] DMAR: DRHD base: 0x00c7ffc000 flags: 0x1 [0.564445] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap d2078c106f0466 ecap f020df [0.580611] DMAR: RMRR base: 0x007bbc6000 end: 0x007bbd4fff [0.593344] DMAR: ATSR flags: 0x0 [0.600178] DMAR: RHSA base: 0x00c7ffc000 proximity domain: 0x0 [0.612905] DMAR: RHSA base: 0x00fbffc000 proximity domain: 0x1 [0.625632] DMAR-IR: IOAPIC id 3 under DRHD base 0xfbffc000 IOMMU 0 [0.638522] DMAR-IR: IOAPIC id 1 under DRHD base 0xc7ffc000 IOMMU 1 [0.651426] DMAR-IR: IOAPIC id 2 under DRHD base 0xc7ffc000 IOMMU 1 [0.664324] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000 [0.675326] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. [0.693805] DMAR-IR: Enabled IRQ remapping in x2apic mode [9.395170] DMAR: dmar1: Using Queued invalidation [9.405011] DMAR: Setting RMRR: [9.412006] DMAR: Setting identity map for device :00:1d.0 [0x7bbc6000 - 0x7bbd4fff] [9.428569] DMAR: Prepare 0-16MiB unity mapping for LPC [9.439712] DMAR: Setting identity map for device :00:1f.0 [0x0 - 0xff] [9.454684] DMAR: Intel(R) Virtualization Technology for Directed I/O [ 287.023068] DMAR: DRHD: handling fault status reg 2 [ 287.023073] DMAR: [DMA Read] Request device [01:00.0] fault addr 18a260a000 [fault reason 06] PTE Read access is not set [ 287.023180] DMAR: DRHD: handling fault status reg 102 [ 287.023183] DMAR: [DMA Read] Request device [01:00.0] fault addr 18a301 [fault reason 06] PTE Read access is not set [ 287.038250] DMAR: DRHD: handling fault status reg 202 [ 287.038252] DMAR: [DMA Read] Request device [01:00.0] fault addr 18a301 [fault reason 06] PTE Read access is not set [ 288.170165] DMAR: DRHD: handling fault status reg 302 [ 288.170170] DMAR: [DMA Read] Request device [01:00.0] fault addr 189075
Re: [dpdk-dev] [PATCH v2] doc: Merge l3fwd and l3fwd-acl documentation files
On Wed, May 10, 2017 at 3:14 AM, Mcnamara, John wrote: > > > > -Original Message- > > From: Ravi Kerur [mailto:rke...@gmail.com] > > Sent: Monday, May 8, 2017 10:00 PM > > To: dev@dpdk.org > > Cc: Mcnamara, John ; tho...@monjalon.net; Ravi > > Kerur > > Subject: [PATCH v2] doc: Merge l3fwd and l3fwd-acl documentation files > > > > Merge l3fwd and l3fwd-acl documentation to reflect the code. > > Add examples of LPM and Exact Match rules in .svg files. > > > > Signed-off-by: Ravi Kerur > > --- > > v2: > > Remove binary PNG from .svg files. > > > > v1: > > Merge relevant contents of l3fwd and l3fwd-acl documentation. > > Modify l3fwd document with ACL specific information. > > Remove l3fwd-acl documentation file. > > --- > > doc/guides/sample_app_ug/img/ipv4_hash_rule.svg| 108 ++ > > doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg | 96 + > > doc/guides/sample_app_ug/index.rst | 1 - > > doc/guides/sample_app_ug/l3_forward.rst| 326 > > - > > .../sample_app_ug/l3_forward_access_ctrl.rst | 385 > > > - > > 5 files changed, 521 insertions(+), 395 deletions(-) create mode 100644 > > doc/guides/sample_app_ug/img/ipv4_hash_rule.svg > > create mode 100644 doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg > > > > > Thanks once more for the doc. Some comments below. > > > > ... > > Redistribution and use in source and binary forms, with or without > @@ > > -31,12 +31,18 @@ > > L3 Forwarding Sample Application > > > > > > -The L3 Forwarding application is a simple example of packet processing > > using the DPDK. > > -The application performs L3 forwarding. > > +The L3 Forwarding with Hash, LPM or Access Control application is a > > simple example of packet processing using the DPDK. > > +The application performs L3 forwarding when Hash or LPM is used. > > +The application performs a security check on received packets when > Access > > Control is used. > > +Packets that are in the Access Control List (ACL), which is loaded > during > > initialization, are dropped. > > +Others are forwarded to the correct port. > > > For the introduction I would suggest the following rewording: > > L3 Forwarding Sample Application > > > The L3 Forwarding application is a simple example of packet processing > using > the DPDK with Hash, LPM (Longest Prefix match) or Access Control. > > The application performs L3 forwarding when Hash or LPM is used. > Alternatively, the application performs a security check on received > packets > when Access Control is used. Packets that are in the Access Control List > (ACL), which is loaded during initialization, are dropped. Others packets > are > forwarded to the correct port. > > > > > > The main difference from the L2 Forwarding sample application is that > the > > forwarding decision @@ -49,15 +55,263 @@ The hash object is used in > > correlation with a flow table to map each input packe The hash lookup > key > > is represented by a DiffServ 5-tuple composed of the following fields > read > > from the input packet: > > Source IP Address, Destination IP Address, Protocol, Source Port and > > Destination Port. > > This is fine but would be a bit clearer as a list: > > > The hash lookup key is represented by a 5-tuple composed of the following > fields read from the input packet: > > * Source IP Address. > * Destination IP Address. > * Protocol. > * Source Port. > * Destination Port. > > > > > + > > +.. _figure_ipv4_lpm_rule: > > + > > +.. figure:: img/ipv4_lpm_rule.* > > + > > + A typical IPv4 LPM rule > > + > > +* A typical IPv4 hash rule line should have a format as shown below: > > + > > + > > +.. _figure_ipv4_hash_rule: > > + > > +.. figure:: img/ipv4_hash_rule.* > > + > > + A typical IPv4 hash rule > > + > > > Unfortunately these figures don't render very well. I would suggest > replacing > them with text, like below: > > > A typical IPv4 LPM rule line in an input file would look like the > following:: > > > # Dest Address/mask Eth port > # = > > L100.10.10.10/24 0 > > > A typical IPv4 Hash rule line in an input file would look like the > following:: > > # Src Address Dst Address Src Port Dst port Protocol Eth port > # === === > > E100.10.10.0 100.10.0.0110 111 0x6 0 > > > There a few other thing that could be improved in the doc but these issues > were > already there in text that you are merging so apart from these suggestion > the rest of the doc is okay for now. We should try to come back and improve > the consistency at a later date. > > Thanks John. Sent a 'v3' with your inputs incorporated. > John > > > > >
[dpdk-dev] [PATCH v3] doc: Merge l3fwd and l3fwd-acl documentation files
Merge l3fwd and l3fwd-acl documentation to reflect the code.
Add examples of LPM and Exact Match rules as text.
Signed-off-by: Ravi Kerur
---
v3:
Incorporate John's comments.
Remove svg files, instead include text format.
v2:
Remove binary PNG from .svg files.
v1:
Merge relevant contents of l3fwd and l3fwd-acl documentation.
Modify l3fwd document with ACL specific information.
Remove l3fwd-acl documentation file.
---
---
doc/guides/sample_app_ug/index.rst | 1 -
doc/guides/sample_app_ug/l3_forward.rst| 332 +-
.../sample_app_ug/l3_forward_access_ctrl.rst | 385 -
3 files changed, 322 insertions(+), 396 deletions(-)
delete mode 100644 doc/guides/sample_app_ug/l3_forward_access_ctrl.rst
diff --git a/doc/guides/sample_app_ug/index.rst
b/doc/guides/sample_app_ug/index.rst
index 02611ef..62cafb0 100644
--- a/doc/guides/sample_app_ug/index.rst
+++ b/doc/guides/sample_app_ug/index.rst
@@ -53,7 +53,6 @@ Sample Applications User Guides
l2_forward_cat
l3_forward
l3_forward_power_man
-l3_forward_access_ctrl
l3_forward_virtual
link_status_intr
load_balancer
diff --git a/doc/guides/sample_app_ug/l3_forward.rst
b/doc/guides/sample_app_ug/l3_forward.rst
index 6a6b8fb..f6a17b8 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -1,5 +1,5 @@
.. BSD LICENSE
-Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
All rights reserved.
Redistribution and use in source and binary forms, with or without
@@ -31,12 +31,20 @@
L3 Forwarding Sample Application
-The L3 Forwarding application is a simple example of packet processing using
the DPDK.
-The application performs L3 forwarding.
+The L3 Forwarding with Hash, LPM or Access Control application is a simple
example of packet processing using
+the DPDK with Hash, LPM (Longest Prefix match) or Access Control..
+The application performs L3 forwarding when Hash or LPM is used.
+Alternatively, the application performs a security check on received packets
+when Access Control is used. Packets that are in the Access Control List
+(ACL), which is loaded during initialization, are dropped. Others packets are
+forwarded to the correct port.
Overview
+Hash and LPM
+
+
The application demonstrates the use of the hash and LPM libraries in the DPDK
to implement packet forwarding.
The initialization and run-time paths are very similar to those of the
:doc:`l2_forward_real_virtual`.
The main difference from the L2 Forwarding sample application is that the
forwarding decision
@@ -47,17 +55,267 @@ a hash object is used to emulate the flow classification
stage.
The hash object is used in correlation with a flow table to map each input
packet to its flow at runtime.
The hash lookup key is represented by a DiffServ 5-tuple composed of the
following fields read from the input packet:
-Source IP Address, Destination IP Address, Protocol, Source Port and
Destination Port.
+
+* Source IP Address.
+* Destination IP Address.
+* Protocol.
+* Source Port.
+* Destination Port.
+
The ID of the output interface for the input packet is read from the
identified flow table entry.
-The set of flows used by the application is statically configured and loaded
into the hash at initialization time.
When the selected lookup method is LPM based, an LPM object is used to emulate
the forwarding stage for IPv4 packets.
The LPM object is used as the routing table to identify the next hop for each
input packet at runtime.
The LPM lookup key is represented by the Destination IP Address field read
from the input packet.
The ID of the output interface for the input packet is the next hop returned
by the LPM lookup.
-The set of LPM rules used by the application is statically configured and
loaded into the LPM object at initialization time.
-In the sample application, hash-based forwarding supports IPv4 and IPv6.
LPM-based forwarding supports IPv4 only.
+In the sample application, both hash-based and LPM forwarding supports IPv4
and IPv6.
+
+The application loads rules at initialization which are used for L3 forwarding.
+The application needs to acquire route rules before it runs.
+
+To read data from the specified file successfully, the application assumes the
following:
+
+* Each rule occupies a single line.
+
+* Only the following four rule line types are valid in this application:
+
+* Route rule line starts with a leading character 'L' for LPM
+
+* Route rule line starts with a leading character 'E' for hash-based
+
+* Comment line, which starts with a leading character '#'
+
+* Empty line, which consists of a space, form-feed ('\f'), newline ('\n'),
+car
Re: [dpdk-dev] [PATCH v1] doc: Merge l3fwd and l3fwd-acl documentation files
On Sun, May 7, 2017 at 1:50 PM, Thomas Monjalon wrote: > Hi, > > 25/04/2017 20:39, Ravi Kerur: > > Merge relevant contents of l3fwd and l3fwd-acl documentation. > > Modify l3fwd document with ACL specific information. > > Remove l3fwd-acl documentation file. > > > > Signed-off-by: Ravi Kerur > > --- > > doc/guides/sample_app_ug/img/ipv4_hash_rule.svg| 158 + > > doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg | 139 > > doc/guides/sample_app_ug/index.rst | 1 - > > doc/guides/sample_app_ug/l3_forward.rst| 326 > - > > .../sample_app_ug/l3_forward_access_ctrl.rst | 385 > - > > 5 files changed, 614 insertions(+), 395 deletions(-) > > create mode 100644 doc/guides/sample_app_ug/img/ipv4_hash_rule.svg > > create mode 100644 doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg > > delete mode 100644 doc/guides/sample_app_ug/l3_forward_access_ctrl.rst > > I've not looked at the content. > I just do not understand why a patch for merging content is adding > some new files. > Moreover, these SVG files contains some binary PNG. > Please send only some source files. > Thanks John and Thomas for review. We have created two new ".svg" files illustrating an example for LPM and Exact Match rules and hence they are reflected in the patch. I have created .svg files directly from inkscape and they now contain only html. I have sent 'v2', please review it and let me know if additional changes are required.
[dpdk-dev] [PATCH v2] doc: Merge l3fwd and l3fwd-acl documentation files
Merge l3fwd and l3fwd-acl documentation to reflect the code. Add examples of LPM and Exact Match rules in .svg files. Signed-off-by: Ravi Kerur --- v2: Remove binary PNG from .svg files. v1: Merge relevant contents of l3fwd and l3fwd-acl documentation. Modify l3fwd document with ACL specific information. Remove l3fwd-acl documentation file. --- doc/guides/sample_app_ug/img/ipv4_hash_rule.svg| 108 ++ doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg | 96 + doc/guides/sample_app_ug/index.rst | 1 - doc/guides/sample_app_ug/l3_forward.rst| 326 - .../sample_app_ug/l3_forward_access_ctrl.rst | 385 - 5 files changed, 521 insertions(+), 395 deletions(-) create mode 100644 doc/guides/sample_app_ug/img/ipv4_hash_rule.svg create mode 100644 doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg delete mode 100644 doc/guides/sample_app_ug/l3_forward_access_ctrl.rst diff --git a/doc/guides/sample_app_ug/img/ipv4_hash_rule.svg b/doc/guides/sample_app_ug/img/ipv4_hash_rule.svg new file mode 100644 index 000..76edfda --- /dev/null +++ b/doc/guides/sample_app_ug/img/ipv4_hash_rule.svg @@ -0,0 +1,108 @@ + + + +http://purl.org/dc/elements/1.1/"; + xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; + width="744.09448819" + height="1052.3622047" + id="svg2" + version="1.1" + inkscape:version="0.48.4 r9939" + sodipodi:docname="New document 1"> + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + E101.0.0.0 100.10.0.0 101 11 0x06 0 + + + + + + Src Addr Dest Addr Src port Dest port ProtocolFwd + diff --git a/doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg b/doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg new file mode 100644 index 000..1b7f02c --- /dev/null +++ b/doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg @@ -0,0 +1,96 @@ + + + +http://purl.org/dc/elements/1.1/"; + xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; + width="744.09448819" + height="1052.3622047" + id="svg2" + version="1.1" + inkscape:version="0.48.4 r9939" + sodipodi:docname="New document 1"> + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + L101.10.1.0/24 0 + + Dest Addr/Prefix Fwd + diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index 02611ef..62cafb0 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -53,7 +53,6 @@ Sample Applications User Guides l2_forward_cat l3_forward l3_forward_power_man -l3_forward_access_ctrl l3_forward_virtual link_status_intr load_balancer diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst index 6a6b8fb..69063bd 100644 --- a/doc/guides/sample_app_ug/l3_forward.rst +++ b/doc/guides/sample_app_ug/l3_forward.rst @@ -1,5 +1,5 @@ .. BSD LICENSE -Copyright(c) 2010-2014 Intel Corporation. All rights reserved. +Copyright(c) 2010-2017 Intel Corporation. All rights reserved. All rights reserved. Redistribution and use in source and binary forms, with or without @@ -31,12 +31,18 @@ L3 Forwarding Sample Application -The L3 Forwarding application is a simple example of packet processing using the DPDK. -The application performs L3 forwarding. +The L3 Forwarding with Hash, LPM or Access Control application is a simple example of packet processing using the DPDK. +The application performs L3 forwarding when Hash or LPM is used. +The application performs a security check on received packets when Access Control is used. +Packets that are in the Access Control List (ACL), which is loaded during initialization, are dropped. +Others are forwarded to the correct port. Overview +Hash and LPM +~~~
[dpdk-dev] [PATCH v1] doc: Merge l3fwd and l3fwd-acl documentation files
Merge relevant contents of l3fwd and l3fwd-acl documentation. Modify l3fwd document with ACL specific information. Remove l3fwd-acl documentation file. Signed-off-by: Ravi Kerur --- doc/guides/sample_app_ug/img/ipv4_hash_rule.svg| 158 + doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg | 139 doc/guides/sample_app_ug/index.rst | 1 - doc/guides/sample_app_ug/l3_forward.rst| 326 - .../sample_app_ug/l3_forward_access_ctrl.rst | 385 - 5 files changed, 614 insertions(+), 395 deletions(-) create mode 100644 doc/guides/sample_app_ug/img/ipv4_hash_rule.svg create mode 100644 doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg delete mode 100644 doc/guides/sample_app_ug/l3_forward_access_ctrl.rst diff --git a/doc/guides/sample_app_ug/img/ipv4_hash_rule.svg b/doc/guides/sample_app_ug/img/ipv4_hash_rule.svg new file mode 100644 index 000..89d563f --- /dev/null +++ b/doc/guides/sample_app_ug/img/ipv4_hash_rule.svg @@ -0,0 +1,158 @@ + + + +http://purl.org/dc/elements/1.1/"; + xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:xlink="http://www.w3.org/1999/xlink"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; + id="svg2" + version="1.1" + inkscape:version="0.91 r13725" + width="819" + height="460" + viewBox="0 0 819 460" + sodipodi:docname="ipv4_hash_rule.svg"> + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + + + diff --git a/doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg b/doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg new file mode 100644 index 000..dcb63b6 --- /dev/null +++ b/doc/guides/sample_app_ug/img/ipv4_lpm_rule.svg @@ -0,0 +1,139 @@ + + + +http://purl.org/dc/elements/1.1/"; + xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:xlink="http://www.w3.org/1999/xlink"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; + id="svg2" + version="1.1" + inkscape:version="0.91 r13725" + width="819" + height="460" + viewBox="0 0 819 460" + sodipodi:docname="ipv4_lpm_rule.svg"> + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + + + diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index 02611ef..62cafb0 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -53,7 +53,6 @@ Sample Applications User Guides l2_forward_cat l3_forward l3_forward_power_man -l3_forward_access_ctrl l3_forward_virtual link_status_intr load_balancer diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst index 6a6b8fb..69063bd 100644 --- a/doc/guides/sample_app_ug/l3_forward.rst +++ b/doc/guides/sample_app_ug/l3_forward.rst @@ -1,5 +1,5 @@ .. BSD LICENSE -Copyright(c) 2010-2014 Intel Corporation. All rights reserved. +Copyright(c) 2010-2017 Intel Corporation. All rights reserved. All rights reserved. Redistribution and use in source and binary forms, with or without @@ -31,12 +31,18 @@ L3 Forwarding Sample Application -The L3 Forwarding application is a simple example of packet processing using the DPDK. -The application performs L3 forwarding. +The L3 Forwarding with Hash, LPM or Access Control application is a simple example of packet processing using the DPDK. +The application performs L3 forwarding when Hash or LPM is used. +The application performs a security check on received packets when Access Control is used. +Packets that are in the Access Control List (ACL), which is loaded during initialization, are dropped. +Others are forwarded to the correct port. Overview +Hash and LPM + + The application demonstrates the use of the hash and LPM libraries in the DPDK to implement packet forwarding. The initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The main difference from the L2 Forwarding sample application is that the forwarding decision @@ -49,15 +55,263 @@ The hash object is used
Re: [dpdk-dev] Q on IXGBE and I40E vector Tx processing
Hi Konstantin, On Sun, Apr 16, 2017 at 3:26 PM, Ananyev, Konstantin < konstantin.anan...@intel.com> wrote: > > Hi Ravi, > > > > > Hi, > > > > The reason I am asking I because I have tried different combinations of > > scalar and vector Tx and Rx processing for both IXGBE and I40E with > > following results > > > > 1. Vector Rx and Vector Tx gives best performance but can only support > > packet size of less than or equal to 2048 bytes > > > > 2. Scalar Rx and Scalar Tx works for all packet size but with degraded > > performance > > > > 3. Vector Rx and Scalar Tx (with certain PMD configuration) works fine > > (performance doesn't meet '1') but it has an inherent bug for packet size > > 8192 bytes as PMD stops packet processing > > > > From the code I see both IXGBE and I40E can support scattered vector Rx, > I > > am curious to know any obvious reasons scattered vector Tx support is > left > > out and does it make sense to implement it? > > > > If it makes sense to implement scattered vector Tx and Intel team hasn't > > worked on it I would like to make an attempt at it so kindly let me know. > > > > Yes, right now there is a tradeoff - simple TX functions (both vector and > scalar) are much > faster than full-featured TX function, but don't support any TX offloads > or multi-segs. > If you'd like to provide a patch that would add some TX offloads to the > simple path > without any performance degradation or either a patch that would improve > performance > of full-featured TX function - I am pretty sure such patches would be > welcomed. > Let me work on it and get back to you for any questions for clarifications. Thanks, > Konstantin > > >
Re: [dpdk-dev] Q on IXGBE and I40E vector Tx processing
Hi, The reason I am asking I because I have tried different combinations of scalar and vector Tx and Rx processing for both IXGBE and I40E with following results 1. Vector Rx and Vector Tx gives best performance but can only support packet size of less than or equal to 2048 bytes 2. Scalar Rx and Scalar Tx works for all packet size but with degraded performance 3. Vector Rx and Scalar Tx (with certain PMD configuration) works fine (performance doesn't meet '1') but it has an inherent bug for packet size 8192 bytes as PMD stops packet processing >From the code I see both IXGBE and I40E can support scattered vector Rx, I am curious to know any obvious reasons scattered vector Tx support is left out and does it make sense to implement it? If it makes sense to implement scattered vector Tx and Intel team hasn't worked on it I would like to make an attempt at it so kindly let me know. Thanks. On Fri, Apr 14, 2017 at 10:35 AM, Ravi Kerur wrote: > Hi, > > We are using dpdk 16.04 and by looking at the ixgbe and > i40e(i40e_xmit_pkts_vec) and ixgbe(ixgbe_xmit_pkts_vec) driver vector tx > processing code I see they both don't handle scattered packet processing. > For any packets greater than 2048 bytes which will basically contain > multiple rte_mbuf segs vector tx processing cannot be used. > > Any reasons why vector tx for both ixgbe and i40e doesn't support > scattered or multiple mbuf segments processing? > > Thanks. >
[dpdk-dev] Q on IXGBE and I40E vector Tx processing
Hi, We are using dpdk 16.04 and by looking at the ixgbe and i40e(i40e_xmit_pkts_vec) and ixgbe(ixgbe_xmit_pkts_vec) driver vector tx processing code I see they both don't handle scattered packet processing. For any packets greater than 2048 bytes which will basically contain multiple rte_mbuf segs vector tx processing cannot be used. Any reasons why vector tx for both ixgbe and i40e doesn't support scattered or multiple mbuf segments processing? Thanks.
Re: [dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd
Hi John, Konstantin,
On Thu, Mar 9, 2017 at 4:07 PM, Ravi Kerur wrote:
> Hi John,
>
> On Thu, Mar 9, 2017 at 2:23 AM, Mcnamara, John
> wrote:
>
>> > From: Ravi Kerur [mailto:rke...@gmail.com]
>> > Sent: Monday, March 6, 2017 11:21 PM
>> > To: Mcnamara, John
>> > Cc: dev@dpdk.org; Ananyev, Konstantin ;
>> > Richardson, Bruce
>> > Subject: Re: [dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd
>> >
>> >
>> > Should I work with documentation team to update the document? If yes,
>> > please let me know the contact information.
>>
>> Hi Ravi,
>>
>> There isn't any documentation team. Unfortunately. :-)
>>
>> The raw documentation is in text format and is generally updated by
>> the developer submitting a patch.
>>
>> There is already docs for l3fwd and l3fwd_acl so all that is required
>> is to merge them. However, you will need to take some care to remove
>> the duplicate sections and to make sure that the merged doc makes
>> sense as a whole.
>>
>> See the documentation guidelines:
>>
>> http://dpdk.org/doc/guides/contributing/documentation.html
>
>
> Thanks. I realized after skimming through the documents and seeing a
> 'doc:' prefix for review. Some clarifications on merging 'l3fwd' and
> 'l3fwd-acl'
>
> 1. Instead of wholesale merger of both 'l3fwd' and 'l3fwd-acl', does it
> make sense to
>
> a. Modify 'l3fwd' document by adding ACL processing information ('-A'
> cmdline) and providing a link or reference to existing 'l3fwd-acl'
> documentation since nothing has changed in terms of 'l3fwd-acl'.
>
> b. Add file read options for 'exact match' and 'longest prefix match' in
> 'l3fwd' documentation.
>
Kindly let me know how you want me to proceed with the changes to
documentation?
Thanks.
>
> Thanks.
>
>>
>>
>> John
>>
>
>
[dpdk-dev] [PATCH v6 3/3] examples/l3fwd: add config file support for exact
Add support to read from config file to build ipv4 and ipv6
exact match forwarding tables.
---
v6:
> Change commit message format
v5:
> No changes.
v4:
> No changes.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings.
v1:
> Remove static array configuration of Dest IP,Src IP, Dest
port, Src port, Proto and IF_OUT for EM and EM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#EM route entries,
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
E101.0.0.0 100.10.0.0 101 11 0x06 0
E201.0.0.0 200.20.0.0 102 12 0x06 1
E111.0.0.0 211.30.0.0 101 11 0x06 2
...
#EM6 route entries
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
Efe80::::021e:67ff:fe00:
fe80::::021b:21ff:fe91:3805 101 11 0x06 0
Efe90::::021e:67ff:fe00:
fe90::::021b:21ff:fe91:3805 102 12 0x06 1
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd_em.c | 376 +-
1 file changed, 303 insertions(+), 73 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 6fdabf7..cd6b443 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -95,8 +95,14 @@ union ipv4_5tuple_host {
#define XMM_NUM_IN_IPV6_5TUPLE 3
struct ipv6_5tuple {
- uint8_t ip_dst[IPV6_ADDR_LEN];
- uint8_t ip_src[IPV6_ADDR_LEN];
+ union {
+ uint8_t ip_dst[IPV6_ADDR_LEN];
+ uint32_t ip32_dst[4];
+ };
+ union {
+ uint8_t ip_src[IPV6_ADDR_LEN];
+ uint32_t ip32_src[4];
+ };
uint16_t port_dst;
uint16_t port_src;
uint8_t proto;
@@ -116,47 +122,24 @@ union ipv6_5tuple_host {
xmm_t xmm[XMM_NUM_IN_IPV6_5TUPLE];
};
-
-
-struct ipv4_l3fwd_em_route {
- struct ipv4_5tuple key;
- uint8_t if_out;
+enum {
+ CB_FLD_DST_ADDR,
+ CB_FLD_SRC_ADDR,
+ CB_FLD_DST_PORT,
+ CB_FLD_SRC_PORT,
+ CB_FLD_PROTO,
+ CB_FLD_IF_OUT,
+ CB_FLD_MAX
};
-struct ipv6_l3fwd_em_route {
- struct ipv6_5tuple key;
+struct em_rule {
+ union {
+ struct ipv4_5tuple v4_key;
+ struct ipv6_5tuple v6_key;
+ };
uint8_t if_out;
};
-static struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
- {{IPv4(101, 0, 0, 0), IPv4(100, 10, 0, 1), 101, 11, IPPROTO_TCP}, 0},
- {{IPv4(201, 0, 0, 0), IPv4(200, 20, 0, 1), 102, 12, IPPROTO_TCP}, 1},
- {{IPv4(111, 0, 0, 0), IPv4(100, 30, 0, 1), 101, 11, IPPROTO_TCP}, 2},
- {{IPv4(211, 0, 0, 0), IPv4(200, 40, 0, 1), 102, 12, IPPROTO_TCP}, 3},
-};
-
-static struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
- {{
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 0},
-
- {{
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 1},
-
- {{
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 2},
-
- {{
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 3},
-};
-
struct rte_hash *ipv4_l3fwd_em_lookup_struct[NB_SOCKETS];
struct rte_hash *ipv6_l3fwd_em_lookup_struct[NB_SOCKETS];
@@ -233,12 +216,6 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t
data_len,
return init_val;
}
-#define IPV4_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv4_l3fwd_em_route_array) /
sizeof(ipv4_l3fwd_em_route_array[0]))
-
-#define IPV6_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv6_l3fwd_em_route_array) /
sizeof(ipv6_l3fwd_em_route_array[0]))
-
static uint8_t ipv4_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
static uint8_t ipv6_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
@@ -338,6 +315,224 @@ em_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid,
void *lookup_struct)
#include "l3fwd_em.h"
#endif
+static int
+em_parse_v6_addr(const char *in, const char **end, uint32_t v[IPV6_ADDR_U32],
+ char dlm)
+{
+ uint32_t addr[IPV6_ADDR_U16];
+
+ GET_CB_FIELD(in, addr[0], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[1], 16, UINT16_MAX
[dpdk-dev] [PATCH v6 1/3] examples/l3fwd: merge l3fwd-acl code into l3fwd
Merge l3fwd-acl code into l3fwd with '-A' cmdline option
to run ACL. Performance critical ACL inline functions are moved
from l3fwd-acl/main.c to l3fwd/l3fwd_acl_scalar.h.
---
v6:
> Change commit message format.
v5:
> None.
v4:
> Initialize rss_hf to IP for LPM, EM and ACL.
> Update rss_hf with l4 in parse_args for ACL.
> Fix pending checkpatch code indentation warning.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch errors and warnings related to non strings
greater than 80 characters.
> MACRO GET_CB_FIELD and strings greater than 80 characters
warnings are not fixed.
v1:
l3fwd-acl changes:
> Merge common init code in l3fwd-acl and l3fwd into main.c.
> Move non-critical inline functions to l3fwd_acl.h.
> Move critial packet processing inline functions to
l3fwd_acl_scalar.h
> Move l3fwd-acl init code to l3fwd_acl.c.
> Delete l3fwd-acl directory.
l3fwd changes:
> Add '-A' as an option for ACL processing.
> Merge parsing options from l3fwd-acl and l3fwd. Retain
l3fwd-acl definitions.
> Move specific setup functions (setup_acl, setup_lpm
and setup_hash).
Testing:
> Compiled successfully for x86_64-native-linuxapp-gcc
> Tested LPM, EM and ACL basic functionality.
Signed-off-by: Ravi Kerur
---
examples/l3fwd-acl/Makefile | 56 -
examples/l3fwd-acl/main.c | 2079 -
examples/l3fwd/Makefile |2 +-
examples/l3fwd/l3fwd.h| 49 +
examples/l3fwd/l3fwd_acl.c| 1064 +++
examples/l3fwd/l3fwd_acl.h| 263 +
examples/l3fwd/l3fwd_acl_scalar.h | 182
examples/l3fwd/l3fwd_em.c | 14 +-
examples/l3fwd/l3fwd_lpm.c| 23 +-
examples/l3fwd/main.c | 209 ++--
10 files changed, 1722 insertions(+), 2219 deletions(-)
delete mode 100644 examples/l3fwd-acl/Makefile
delete mode 100644 examples/l3fwd-acl/main.c
create mode 100644 examples/l3fwd/l3fwd_acl.c
create mode 100644 examples/l3fwd/l3fwd_acl.h
create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h
diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile
deleted file mode 100644
index a3473a8..000
--- a/examples/l3fwd-acl/Makefile
+++ /dev/null
@@ -1,56 +0,0 @@
-# BSD LICENSE
-#
-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-# All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-# * Redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in
-# the documentation and/or other materials provided with the
-# distribution.
-# * Neither the name of Intel Corporation nor the names of its
-# contributors may be used to endorse or promote products derived
-# from this software without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-ifeq ($(RTE_SDK),)
-$(error "Please define RTE_SDK environment variable")
-endif
-
-# Default target, can be overriden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
-
-include $(RTE_SDK)/mk/rte.vars.mk
-
-# binary name
-APP = l3fwd-acl
-
-# all source are stored in SRCS-y
-SRCS-y := main.c
-
-CFLAGS += -O3
-CFLAGS += $(WERROR_FLAGS)
-
-# workaround for a gcc bug with noreturn attribute
-# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
-ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
-CFLAGS_main.o += -Wno-return-type
-endif
-
-include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/l3fwd-acl/main.c b/
[dpdk-dev] [PATCH v6 2/3] examples/l3fwd: add config file support for lpm
Add support to read from config file to build ipv4 and ipv6
longest prefix match forwarding tables.
---
v6:
> Change commit message format.
v5:
> Change is_bypass_line from inline to non-line.
v4:
> No changes.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings related to code
> MACRO GET_CB_FIELD checkpatch warning not fixed
v1:
> Remove static array configuration of Destination IP, MASK
and IF_OUT for LPM and LPM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#LPM route entries Dest-IP/Mask IF_OUT
L1.1.1.0/24 0
L2.1.1.0/24 1
L3.1.1.0/24 2
...
#LPM6 route entries Dest-IP/Mask IF_OUT
L:::::::/48 0
L2111:::::::/48 1
L3111:::::::/48 2
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd.h | 28 +
examples/l3fwd/l3fwd_acl.c | 39 +-
examples/l3fwd/l3fwd_acl.h | 29 -
examples/l3fwd/l3fwd_lpm.c | 308 +
examples/l3fwd/main.c | 47 ++-
5 files changed, 332 insertions(+), 119 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 93e08f6..aa4bd25 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -94,6 +94,29 @@
#define ACL_LEAD_CHAR ('@')
#define ROUTE_LEAD_CHAR('R')
#define COMMENT_LEAD_CHAR ('#')
+#define LPM_LEAD_CHAR ('L')
+#define EM_LEAD_CHAR ('E')
+
+#defineIPV6_ADDR_LEN 16
+#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
+#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
+
+#define GET_CB_FIELD(in, fd, base, lim, dlm) do {\
+ unsigned long val; \
+ char *end; \
+ errno = 0; \
+ val = strtoul((in), &end, (base)); \
+ if (errno != 0 || end[0] != (dlm) || val > (lim)) \
+ return -EINVAL; \
+ (fd) = (typeof(fd))val; \
+ (in) = end + 1; \
+} while (0)
+
+struct parm_cfg {
+ const char *rule_ipv4_name;
+ const char *rule_ipv6_name;
+ int scalar;
+};
struct mbuf_table {
uint16_t len;
@@ -134,6 +157,8 @@ extern xmm_t val_eth[RTE_MAX_ETHPORTS];
extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+extern struct parm_cfg parm_config;
+
extern int numa_on; /**< NUMA is enabled by default. */
/* Send burst of packets on an output interface */
@@ -287,4 +312,7 @@ l3fwd_acl_set_rule_ipv6_name(const char *optarg);
void
l3fwd_acl_set_rule_ipv4_name(const char *optarg);
+int
+is_bypass_line(const char *buff);
+
#endif /* __L3_FWD_H__ */
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index 388b978..66ed23d 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -147,10 +147,6 @@ struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
},
};
-#defineIPV6_ADDR_LEN 16
-#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
-#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
-
enum {
PROTO_FIELD_IPV6,
SRC1_FIELD_IPV6,
@@ -297,12 +293,6 @@ static struct {
const char cb_port_delim[] = ":";
-static struct {
- const char *rule_ipv4_name;
- const char *rule_ipv6_name;
- int scalar;
-} parm_config;
-
/*
* Print and dump ACL/Route rules functions are defined in
* following header file.
@@ -316,27 +306,6 @@ static struct {
#include "l3fwd_acl_scalar.h"
/*
- * API's called during initialization to setup ACL rules.
- */
-void
-l3fwd_acl_set_rule_ipv4_name(const char *optarg)
-{
- parm_config.rule_ipv4_name = optarg;
-}
-
-void
-l3fwd_acl_set_rule_ipv6_name(const char *optarg)
-{
- parm_config.rule_ipv6_name = optarg;
-}
-
-void
-l3fwd_acl_set_scalar(void)
-{
- parm_config.scalar = 1;
-}
-
-/*
* Parses IPV6 address, exepcts the following format:
* ::::::: (where X - is a hexedecimal digit).
*/
@@ -566,7 +535,7 @@ parse_cb_ipv4vlan_rule(char *str, struct rte_acl_rule *v,
int has_userdata)
}
static int
-add_rules(const char *rule_path,
+acl_add_rules(const char *rule_path,
struct rte_acl_rule **proute_base,
unsigned int *proute_num,
struct rte_acl_rule **pacl_base,
@@ -764,8 +733,8 @@ setup_acl(c
[dpdk-dev] [PATCH v6 0/3] examples/l3fwd: merge l3fwd-acl code into l3fwd
This patchset merges l3fwd-acl and l3fwd code into common directory. Adds config file read option to build LPM and EM tables. Ravi Kerur (3): examples/l3fwd: merge l3fwd-acl code into l3fwd examples/l3fwd: add config file support for lpm examples/l3fwd: add config file support for exact examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 77 ++ examples/l3fwd/l3fwd_acl.c| 1033 ++ examples/l3fwd/l3fwd_acl.h| 234 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 390 +-- examples/l3fwd/l3fwd_lpm.c| 323 -- examples/l3fwd/main.c | 250 +++-- 10 files changed, 2286 insertions(+), 2340 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h -- 2.7.4
Re: [dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd
Hi John,
On Thu, Mar 9, 2017 at 2:23 AM, Mcnamara, John
wrote:
> > From: Ravi Kerur [mailto:rke...@gmail.com]
> > Sent: Monday, March 6, 2017 11:21 PM
> > To: Mcnamara, John
> > Cc: dev@dpdk.org; Ananyev, Konstantin ;
> > Richardson, Bruce
> > Subject: Re: [dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd
> >
> >
> > Should I work with documentation team to update the document? If yes,
> > please let me know the contact information.
>
> Hi Ravi,
>
> There isn't any documentation team. Unfortunately. :-)
>
> The raw documentation is in text format and is generally updated by
> the developer submitting a patch.
>
> There is already docs for l3fwd and l3fwd_acl so all that is required
> is to merge them. However, you will need to take some care to remove
> the duplicate sections and to make sure that the merged doc makes
> sense as a whole.
>
> See the documentation guidelines:
>
> http://dpdk.org/doc/guides/contributing/documentation.html
Thanks. I realized after skimming through the documents and seeing a 'doc:'
prefix for review. Some clarifications on merging 'l3fwd' and 'l3fwd-acl'
1. Instead of wholesale merger of both 'l3fwd' and 'l3fwd-acl', does it
make sense to
a. Modify 'l3fwd' document by adding ACL processing information ('-A'
cmdline) and providing a link or reference to existing 'l3fwd-acl'
documentation since nothing has changed in terms of 'l3fwd-acl'.
b. Add file read options for 'exact match' and 'longest prefix match' in
'l3fwd' documentation.
Thanks.
>
>
> John
>
Re: [dpdk-dev] [PATCH v5 3/3] examples/l3fwd: add config file support for EM
Hi John, On Thu, Mar 9, 2017 at 2:45 AM, Mcnamara, John wrote: > > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ravi Kerur > > Sent: Wednesday, March 8, 2017 9:32 PM > > To: dev@dpdk.org; Ananyev, Konstantin ; > > Richardson, Bruce > > Cc: Ravi Kerur > > Subject: [dpdk-dev] [PATCH v5 3/3] examples/l3fwd: add config file > support > > for EM > > > > Add config file support for v4 and v6 to build exact match forwarding > > tables. > > Hi Ravi, > > Same comment about Ipv4 and IPv6 and ---. > > Also it is probably better to use "exact match" instead of "EM" in the > subject. It isn't as well known an acronym as LPM. > > I will make changes to all patches and send out updated version. Thanks. > John >
Re: [dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd
John, Konstantin, Kindly let me know new 'v5' patch follows dpdk guidelines? I just followed what's in the dpdk contributing code guidelines. - git format-patch -3 -o patch/ -v 5 --cover-letter - git send-email --to dev@dpdk.org --in-reply-to patch/* Thanks. On Mon, Mar 6, 2017 at 3:20 PM, Ravi Kerur wrote: > Hi John, > > Should I work with documentation team to update the document? If yes, > please let me know the contact information. > > Thanks. > > On Mon, Mar 6, 2017 at 5:33 AM, Mcnamara, John > wrote: > >> > -Original Message- >> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ravi Kerur >> > Sent: Sunday, March 5, 2017 7:47 PM >> > To: dev@dpdk.org >> > Cc: Ananyev, Konstantin ; Richardson, >> Bruce >> > ; Ravi Kerur >> > Subject: [dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd >> > >> > This patchset merges l3fwd-acl and l3fwd code into common directory. >> > Adds file read options to build LPM and EM tables. >> >> Hi Ravi, >> >> Thanks to this. It seems like a good change. There are probably too many >> L2/L3 variants and some of them should be merged. >> >> Note, you will also have to merge the sample app guides in some sensible >> way: >> >> http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html >> http://dpdk.org/doc/guides/sample_app_ug/l3_forward_access_ctrl.html >> >> John >> >> >
[dpdk-dev] [PATCH v5 1/3] examples/l3fwd: merge l3fwd-acl code into l3fwd
Merge l3fwd-acl code into l3fwd with '-A' cmdline option to run ACL.
v5:
> None.
v4:
> Initialize rss_hf to IP for LPM, EM and ACL.
> Update rss_hf with l4 in parse_args for ACL.
> Fix pending checkpatch code indentation warning.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch errors and warnings related to non strings
greater than 80 characters.
> MACRO GET_CB_FIELD and strings greater than 80 characters
warnings are not fixed.
v1:
l3fwd-acl changes:
> Merge common init code in l3fwd-acl and l3fwd into
main.c.
> Move non-critical inline functions to l3fwd_acl.h.
> Move critial packet processing inline functions to
l3fwd_acl_scalar.h
> Move l3fwd-acl init code to l3fwd_acl.c.
> Delete l3fwd-acl directory.
l3fwd changes:
> Add '-A' as an option for ACL processing.
> Merge parsing options from l3fwd-acl and l3fwd. Retain
l3fwd-acl definitions.
> Move specific setup functions (setup_acl, setup_lpm
and setup_hash).
Testing:
> Compiled successfully for x86_64-native-linuxapp-gcc
> Tested LPM, EM and ACL basic functionality.
Signed-off-by: Ravi Kerur
---
examples/l3fwd-acl/Makefile | 56 -
examples/l3fwd-acl/main.c | 2079 -
examples/l3fwd/Makefile |2 +-
examples/l3fwd/l3fwd.h| 49 +
examples/l3fwd/l3fwd_acl.c| 1064 +++
examples/l3fwd/l3fwd_acl.h| 263 +
examples/l3fwd/l3fwd_acl_scalar.h | 182
examples/l3fwd/l3fwd_em.c | 14 +-
examples/l3fwd/l3fwd_lpm.c| 23 +-
examples/l3fwd/main.c | 209 ++--
10 files changed, 1722 insertions(+), 2219 deletions(-)
delete mode 100644 examples/l3fwd-acl/Makefile
delete mode 100644 examples/l3fwd-acl/main.c
create mode 100644 examples/l3fwd/l3fwd_acl.c
create mode 100644 examples/l3fwd/l3fwd_acl.h
create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h
diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile
deleted file mode 100644
index a3473a8..000
--- a/examples/l3fwd-acl/Makefile
+++ /dev/null
@@ -1,56 +0,0 @@
-# BSD LICENSE
-#
-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-# All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-# * Redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in
-# the documentation and/or other materials provided with the
-# distribution.
-# * Neither the name of Intel Corporation nor the names of its
-# contributors may be used to endorse or promote products derived
-# from this software without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-ifeq ($(RTE_SDK),)
-$(error "Please define RTE_SDK environment variable")
-endif
-
-# Default target, can be overriden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
-
-include $(RTE_SDK)/mk/rte.vars.mk
-
-# binary name
-APP = l3fwd-acl
-
-# all source are stored in SRCS-y
-SRCS-y := main.c
-
-CFLAGS += -O3
-CFLAGS += $(WERROR_FLAGS)
-
-# workaround for a gcc bug with noreturn attribute
-# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
-ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
-CFLAGS_main.o += -Wno-return-type
-endif
-
-include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c
deleted file mode 100644
index 3cfbb40..000
--- a/examples/l3fwd-acl/main.c
+++ /dev/null
@
[dpdk-dev] [PATCH v5 3/3] examples/l3fwd: add config file support for EM
Add config file support for v4 and v6 to build exact match
forwarding tables.
v5:
> No changes.
v4:
> No changes.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings.
v1:
> Remove static array configuration of Dest IP,Src IP, Dest
port, Src port, Proto and IF_OUT for EM and EM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#EM route entries,
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
E101.0.0.0 100.10.0.0 101 11 0x06 0
E201.0.0.0 200.20.0.0 102 12 0x06 1
E111.0.0.0 211.30.0.0 101 11 0x06 2
...
#EM6 route entries
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
Efe80::::021e:67ff:fe00:
fe80::::021b:21ff:fe91:3805 101 11 0x06 0
Efe90::::021e:67ff:fe00:
fe90::::021b:21ff:fe91:3805 102 12 0x06 1
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd_em.c | 376 +-
1 file changed, 303 insertions(+), 73 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 6fdabf7..cd6b443 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -95,8 +95,14 @@ union ipv4_5tuple_host {
#define XMM_NUM_IN_IPV6_5TUPLE 3
struct ipv6_5tuple {
- uint8_t ip_dst[IPV6_ADDR_LEN];
- uint8_t ip_src[IPV6_ADDR_LEN];
+ union {
+ uint8_t ip_dst[IPV6_ADDR_LEN];
+ uint32_t ip32_dst[4];
+ };
+ union {
+ uint8_t ip_src[IPV6_ADDR_LEN];
+ uint32_t ip32_src[4];
+ };
uint16_t port_dst;
uint16_t port_src;
uint8_t proto;
@@ -116,47 +122,24 @@ union ipv6_5tuple_host {
xmm_t xmm[XMM_NUM_IN_IPV6_5TUPLE];
};
-
-
-struct ipv4_l3fwd_em_route {
- struct ipv4_5tuple key;
- uint8_t if_out;
+enum {
+ CB_FLD_DST_ADDR,
+ CB_FLD_SRC_ADDR,
+ CB_FLD_DST_PORT,
+ CB_FLD_SRC_PORT,
+ CB_FLD_PROTO,
+ CB_FLD_IF_OUT,
+ CB_FLD_MAX
};
-struct ipv6_l3fwd_em_route {
- struct ipv6_5tuple key;
+struct em_rule {
+ union {
+ struct ipv4_5tuple v4_key;
+ struct ipv6_5tuple v6_key;
+ };
uint8_t if_out;
};
-static struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
- {{IPv4(101, 0, 0, 0), IPv4(100, 10, 0, 1), 101, 11, IPPROTO_TCP}, 0},
- {{IPv4(201, 0, 0, 0), IPv4(200, 20, 0, 1), 102, 12, IPPROTO_TCP}, 1},
- {{IPv4(111, 0, 0, 0), IPv4(100, 30, 0, 1), 101, 11, IPPROTO_TCP}, 2},
- {{IPv4(211, 0, 0, 0), IPv4(200, 40, 0, 1), 102, 12, IPPROTO_TCP}, 3},
-};
-
-static struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
- {{
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 0},
-
- {{
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 1},
-
- {{
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 2},
-
- {{
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 3},
-};
-
struct rte_hash *ipv4_l3fwd_em_lookup_struct[NB_SOCKETS];
struct rte_hash *ipv6_l3fwd_em_lookup_struct[NB_SOCKETS];
@@ -233,12 +216,6 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t
data_len,
return init_val;
}
-#define IPV4_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv4_l3fwd_em_route_array) /
sizeof(ipv4_l3fwd_em_route_array[0]))
-
-#define IPV6_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv6_l3fwd_em_route_array) /
sizeof(ipv6_l3fwd_em_route_array[0]))
-
static uint8_t ipv4_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
static uint8_t ipv6_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
@@ -338,6 +315,224 @@ em_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid,
void *lookup_struct)
#include "l3fwd_em.h"
#endif
+static int
+em_parse_v6_addr(const char *in, const char **end, uint32_t v[IPV6_ADDR_U32],
+ char dlm)
+{
+ uint32_t addr[IPV6_ADDR_U16];
+
+ GET_CB_FIELD(in, addr[0], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[1], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[2], 16, UIN
[dpdk-dev] [PATCH v5 2/3] examples/l3fwd: add config file support for LPM
Add config file support for v4 and v6 to build forwarding
tables.
v5:
> Changes is_bypass_line from inline to non-line.
v4:
> No changes.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings related to code
> MACRO GET_CB_FIELD checkpatch warning not fixed
v1:
> Remove static array configuration of Destination IP, MASK
and IF_OUT for LPM and LPM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#LPM route entries Dest-IP/Mask IF_OUT
L1.1.1.0/24 0
L2.1.1.0/24 1
L3.1.1.0/24 2
...
#LPM6 route entries Dest-IP/Mask IF_OUT
L:::::::/48 0
L2111:::::::/48 1
L3111:::::::/48 2
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd.h | 28 +
examples/l3fwd/l3fwd_acl.c | 39 +-
examples/l3fwd/l3fwd_acl.h | 29 -
examples/l3fwd/l3fwd_lpm.c | 308 +
examples/l3fwd/main.c | 47 ++-
5 files changed, 332 insertions(+), 119 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 93e08f6..35f7b72 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -94,6 +94,29 @@
#define ACL_LEAD_CHAR ('@')
#define ROUTE_LEAD_CHAR('R')
#define COMMENT_LEAD_CHAR ('#')
+#define LPM_LEAD_CHAR ('L')
+#define EM_LEAD_CHAR ('E')
+
+#defineIPV6_ADDR_LEN 16
+#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
+#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
+
+#define GET_CB_FIELD(in, fd, base, lim, dlm) do {\
+ unsigned long val; \
+ char *end; \
+ errno = 0; \
+ val = strtoul((in), &end, (base)); \
+ if (errno != 0 || end[0] != (dlm) || val > (lim)) \
+ return -EINVAL; \
+ (fd) = (typeof(fd))val; \
+ (in) = end + 1; \
+} while (0)
+
+struct parm_cfg {
+ const char *rule_ipv4_name;
+ const char *rule_ipv6_name;
+ int scalar;
+};
struct mbuf_table {
uint16_t len;
@@ -134,6 +157,8 @@ extern xmm_t val_eth[RTE_MAX_ETHPORTS];
extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+extern struct parm_cfg parm_config;
+
extern int numa_on; /**< NUMA is enabled by default. */
/* Send burst of packets on an output interface */
@@ -287,4 +312,7 @@ l3fwd_acl_set_rule_ipv6_name(const char *optarg);
void
l3fwd_acl_set_rule_ipv4_name(const char *optarg);
+int
+is_bypass_line(char *buff);
+
#endif /* __L3_FWD_H__ */
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index 388b978..66ed23d 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -147,10 +147,6 @@ struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
},
};
-#defineIPV6_ADDR_LEN 16
-#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
-#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
-
enum {
PROTO_FIELD_IPV6,
SRC1_FIELD_IPV6,
@@ -297,12 +293,6 @@ static struct {
const char cb_port_delim[] = ":";
-static struct {
- const char *rule_ipv4_name;
- const char *rule_ipv6_name;
- int scalar;
-} parm_config;
-
/*
* Print and dump ACL/Route rules functions are defined in
* following header file.
@@ -316,27 +306,6 @@ static struct {
#include "l3fwd_acl_scalar.h"
/*
- * API's called during initialization to setup ACL rules.
- */
-void
-l3fwd_acl_set_rule_ipv4_name(const char *optarg)
-{
- parm_config.rule_ipv4_name = optarg;
-}
-
-void
-l3fwd_acl_set_rule_ipv6_name(const char *optarg)
-{
- parm_config.rule_ipv6_name = optarg;
-}
-
-void
-l3fwd_acl_set_scalar(void)
-{
- parm_config.scalar = 1;
-}
-
-/*
* Parses IPV6 address, exepcts the following format:
* ::::::: (where X - is a hexedecimal digit).
*/
@@ -566,7 +535,7 @@ parse_cb_ipv4vlan_rule(char *str, struct rte_acl_rule *v,
int has_userdata)
}
static int
-add_rules(const char *rule_path,
+acl_add_rules(const char *rule_path,
struct rte_acl_rule **proute_base,
unsigned int *proute_num,
struct rte_acl_rule **pacl_base,
@@ -764,8 +733,8 @@ setup_acl(const int socket_id __attribute__((unused)))
dump_acl_config();
-
[dpdk-dev] [PATCH v5 0/3] examples/l3fwd: merge l3fwd-acl code into l3fwd
This patchset merges l3fwd-acl and l3fwd code into common directory. Adds file read options to build LPM and EM tables. Ravi Kerur (3): examples/l3fwd: Merge l3fwd-acl code into l3fwd examples/l3fwd: add config file support for LPM examples/l3fwd: add config file support for EM examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 77 ++ examples/l3fwd/l3fwd_acl.c| 1033 ++ examples/l3fwd/l3fwd_acl.h| 234 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 390 +-- examples/l3fwd/l3fwd_lpm.c| 323 -- examples/l3fwd/main.c | 250 +++-- 10 files changed, 2286 insertions(+), 2340 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h -- 2.7.4
Re: [dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd
Hi John, Should I work with documentation team to update the document? If yes, please let me know the contact information. Thanks. On Mon, Mar 6, 2017 at 5:33 AM, Mcnamara, John wrote: > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ravi Kerur > > Sent: Sunday, March 5, 2017 7:47 PM > > To: dev@dpdk.org > > Cc: Ananyev, Konstantin ; Richardson, > Bruce > > ; Ravi Kerur > > Subject: [dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd > > > > This patchset merges l3fwd-acl and l3fwd code into common directory. > > Adds file read options to build LPM and EM tables. > > Hi Ravi, > > Thanks to this. It seems like a good change. There are probably too many > L2/L3 variants and some of them should be merged. > > Note, you will also have to merge the sample app guides in some sensible > way: > > http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html > http://dpdk.org/doc/guides/sample_app_ug/l3_forward_access_ctrl.html > > John > >
Re: [dpdk-dev] [v3 2/3] LPM config file read option.
Sure Stephen will make the changes.
On Mon, Mar 6, 2017 at 8:46 AM, Stephen Hemminger <
step...@networkplumber.org> wrote:
> On Sat, 4 Mar 2017 12:44:18 -0800
> Ravi Kerur wrote:
>
> > +/* Bypass comment and empty lines */
> > +static inline int
> > +is_bypass_line(char *buff)
> > +{
> > + int i = 0;
> > +
> > + /* comment line */
> > + if (buff[0] == COMMENT_LEAD_CHAR)
> > + return 1;
> > + /* empty line */
> > + while (buff[i] != '\0') {
> > + if (!isspace(buff[i]))
> > + return 0;
> > + i++;
> > + }
> > + return 1;
> > +}
>
> This is not performance crtitical should not be inline.
> The argument is never modified and therefore should be "const char *buff"
>
Re: [dpdk-dev] [RFC 17.05 v1 0/3] Merge l3fwd-acl and l3fwd
Hi Konstantin,
Thanks for the inputs.
Initialization starts with ETH_RSS_IP and gets updated with L4 if ACL is
selected in parse_args function. This change is to fix rss_hf.
I have submitted 'v4' patch, please let me know if additional changes are
needed.
Thanks.
On Sun, Mar 5, 2017 at 5:15 AM, Ananyev, Konstantin <
konstantin.anan...@intel.com> wrote:
>
> Hi Ravi,
>
> >
> > Hi Konstantin,
> >
> > Sorry for this one, I had to resend patch series as 'v3' as additional
> checkpatch warnings were seen after the submission which didn't show
> > up in my run.
> >
> > 'v3' patch should have all fixed except the ones I mentioned in my
> earlier email on which I need inputs from you.
> >
> > Thanks.
> >
> > On Sat, Mar 4, 2017 at 11:49 AM, Ravi Kerur wrote:
> > Hi Konstantin,
> >
> > I have sent 'v2' patchset. I need clarifications on following things, if
> they should be fixed I will send out 'v3' so please let me know.
> >
> > Following code changes were done by me manually, not merged.
> > +++ b/examples/l3fwd/main.c
> > @@ -161,7 +163,9 @@ static struct rte_eth_conf port_conf = {
> > .rx_adv_conf = {
> > .rss_conf = {
> > .rss_key = NULL,
> > - .rss_hf = ETH_RSS_IP,
> > + .rss_hf = ETH_RSS_IP | ETH_RSS_UDP |
> > + ETH_RSS_TCP | ETH_RSS_SCTP,
> > +
> > },
> >
> > The reason I did it is because
> >
> > LPM/EM has .rss_hf = ETH_RSS_IP
> > ACL has .rss_hf = ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP | ETH_RSS_SCTP,
> >
> > ACL looks like a superset of LPM/EM and functional testing didn't reveal
> any issues hence I kept ACL version.
>
> But at least for LPM, we probably don't want L4 ports affect packet
> distribution?
> Probably the safest way would be to have a separate port_conf for each
> case (LPM/EM/ACL).
> That way will preserve the original behavior.
>
> >
> > 2. Checkpatch errors are all fixed. Some warnings are not fixed and they
> are
> >
> > 2.a, string length greater than 80 characters
> > 2.b GET_CB_FIELD macro. I could have changed GET_CB_FIELD to inline
> function, however, function names cannot be in capital letters. I
> > could have changed it to 'get_cb_field' inline function, but didn't do
> it as I thought it may not be worth the change.
>
> It is ok by me to leave as it is by now.
> Thanks
> Konstantin
>
>
>
>
[dpdk-dev] [v4 1/3] Merge l3fwd-acl and l3fwd code.
v4: > Initialize rss_hf to IP for LPM, EM and ACL. > Update rss_hf with l4 in parse_args for ACL. > Fix pending checkpatch code indentation warning. v3: > Fix additional checkpatch coding style issues. v2: > Fix checkpatch errors and warnings related to non strings greater than 80 characters. > MACRO GET_CB_FIELD and strings greater than 80 characters warnings are not fixed. v1: l3fwd-acl changes: > Merge common init code in l3fwd-acl and l3fwd into main.c. > Move non-critical inline functions to l3fwd_acl.h. > Move critial packet processing inline functions to l3fwd_acl_scalar.h > Move l3fwd-acl init code to l3fwd_acl.c. > Delete l3fwd-acl directory. l3fwd changes: > Add '-A' as an option for ACL processing. > Merge parsing options from l3fwd-acl and l3fwd. Retain l3fwd-acl definitions. > Move specific setup functions (setup_acl, setup_lpm and setup_hash). Testing: > Compiled successfully for x86_64-native-linuxapp-gcc > Tested LPM, EM and ACL basic functionality. Signed-off-by: Ravi Kerur --- examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 49 + examples/l3fwd/l3fwd_acl.c| 1064 +++ examples/l3fwd/l3fwd_acl.h| 263 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 14 +- examples/l3fwd/l3fwd_lpm.c| 23 +- examples/l3fwd/main.c | 209 ++-- 10 files changed, 1722 insertions(+), 2219 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile deleted file mode 100644 index a3473a8..000 --- a/examples/l3fwd-acl/Makefile +++ /dev/null @@ -1,56 +0,0 @@ -# BSD LICENSE -# -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of Intel Corporation nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -ifeq ($(RTE_SDK),) -$(error "Please define RTE_SDK environment variable") -endif - -# Default target, can be overriden by command line or environment -RTE_TARGET ?= x86_64-native-linuxapp-gcc - -include $(RTE_SDK)/mk/rte.vars.mk - -# binary name -APP = l3fwd-acl - -# all source are stored in SRCS-y -SRCS-y := main.c - -CFLAGS += -O3 -CFLAGS += $(WERROR_FLAGS) - -# workaround for a gcc bug with noreturn attribute -# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 -ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) -CFLAGS_main.o += -Wno-return-type -endif - -include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c deleted file mode 100644 index 3cfbb40..000 --- a/examples/l3fwd-acl/main.c +++ /dev/null @@ -1,2079 +0,0 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2010-2016 Intel Corporation. All rights r
[dpdk-dev] [v4 3/3] EM config file read option.
v4:
> No changes.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings.
v1:
> Remove static array configuration of Dest IP,Src IP, Dest
port, Src port, Proto and IF_OUT for EM and EM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#EM route entries,
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
E101.0.0.0 100.10.0.0 101 11 0x06 0
E201.0.0.0 200.20.0.0 102 12 0x06 1
E111.0.0.0 211.30.0.0 101 11 0x06 2
...
#EM6 route entries
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
Efe80::::021e:67ff:fe00:
fe80::::021b:21ff:fe91:3805 101 11 0x06 0
Efe90::::021e:67ff:fe00:
fe90::::021b:21ff:fe91:3805 102 12 0x06 1
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd_em.c | 376 +-
1 file changed, 303 insertions(+), 73 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 6fdabf7..cd6b443 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -95,8 +95,14 @@ union ipv4_5tuple_host {
#define XMM_NUM_IN_IPV6_5TUPLE 3
struct ipv6_5tuple {
- uint8_t ip_dst[IPV6_ADDR_LEN];
- uint8_t ip_src[IPV6_ADDR_LEN];
+ union {
+ uint8_t ip_dst[IPV6_ADDR_LEN];
+ uint32_t ip32_dst[4];
+ };
+ union {
+ uint8_t ip_src[IPV6_ADDR_LEN];
+ uint32_t ip32_src[4];
+ };
uint16_t port_dst;
uint16_t port_src;
uint8_t proto;
@@ -116,47 +122,24 @@ union ipv6_5tuple_host {
xmm_t xmm[XMM_NUM_IN_IPV6_5TUPLE];
};
-
-
-struct ipv4_l3fwd_em_route {
- struct ipv4_5tuple key;
- uint8_t if_out;
+enum {
+ CB_FLD_DST_ADDR,
+ CB_FLD_SRC_ADDR,
+ CB_FLD_DST_PORT,
+ CB_FLD_SRC_PORT,
+ CB_FLD_PROTO,
+ CB_FLD_IF_OUT,
+ CB_FLD_MAX
};
-struct ipv6_l3fwd_em_route {
- struct ipv6_5tuple key;
+struct em_rule {
+ union {
+ struct ipv4_5tuple v4_key;
+ struct ipv6_5tuple v6_key;
+ };
uint8_t if_out;
};
-static struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
- {{IPv4(101, 0, 0, 0), IPv4(100, 10, 0, 1), 101, 11, IPPROTO_TCP}, 0},
- {{IPv4(201, 0, 0, 0), IPv4(200, 20, 0, 1), 102, 12, IPPROTO_TCP}, 1},
- {{IPv4(111, 0, 0, 0), IPv4(100, 30, 0, 1), 101, 11, IPPROTO_TCP}, 2},
- {{IPv4(211, 0, 0, 0), IPv4(200, 40, 0, 1), 102, 12, IPPROTO_TCP}, 3},
-};
-
-static struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
- {{
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 0},
-
- {{
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 1},
-
- {{
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 2},
-
- {{
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 3},
-};
-
struct rte_hash *ipv4_l3fwd_em_lookup_struct[NB_SOCKETS];
struct rte_hash *ipv6_l3fwd_em_lookup_struct[NB_SOCKETS];
@@ -233,12 +216,6 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t
data_len,
return init_val;
}
-#define IPV4_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv4_l3fwd_em_route_array) /
sizeof(ipv4_l3fwd_em_route_array[0]))
-
-#define IPV6_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv6_l3fwd_em_route_array) /
sizeof(ipv6_l3fwd_em_route_array[0]))
-
static uint8_t ipv4_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
static uint8_t ipv6_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
@@ -338,6 +315,224 @@ em_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid,
void *lookup_struct)
#include "l3fwd_em.h"
#endif
+static int
+em_parse_v6_addr(const char *in, const char **end, uint32_t v[IPV6_ADDR_U32],
+ char dlm)
+{
+ uint32_t addr[IPV6_ADDR_U16];
+
+ GET_CB_FIELD(in, addr[0], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[1], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[2], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[3], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in,
[dpdk-dev] [v4 0/3] Merge l3fwd-acl and l3fwd
This patchset merges l3fwd-acl and l3fwd code into common directory. Adds file read options to build LPM and EM tables. Ravi Kerur (3): Merge l3fwd-acl and l3fwd code. LPM config file read option. EM config file read option. examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 92 ++ examples/l3fwd/l3fwd_acl.c| 1033 ++ examples/l3fwd/l3fwd_acl.h| 234 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 390 +-- examples/l3fwd/l3fwd_lpm.c| 323 -- examples/l3fwd/main.c | 232 +++-- 10 files changed, 2283 insertions(+), 2340 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h -- 2.7.4
[dpdk-dev] [v4 2/3] LPM config file read option.
v4:
> No changes.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings related to code
> MACRO GET_CB_FIELD checkpatch warning not fixed
v1:
> Remove static array configuration of Destination IP, MASK
and IF_OUT for LPM and LPM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#LPM route entries Dest-IP/Mask IF_OUT
L1.1.1.0/24 0
L2.1.1.0/24 1
L3.1.1.0/24 2
...
#LPM6 route entries Dest-IP/Mask IF_OUT
L:::::::/48 0
L2111:::::::/48 1
L3111:::::::/48 2
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd.h | 43 +++
examples/l3fwd/l3fwd_acl.c | 39 +-
examples/l3fwd/l3fwd_acl.h | 29 -
examples/l3fwd/l3fwd_lpm.c | 308 +
examples/l3fwd/main.c | 29 -
5 files changed, 329 insertions(+), 119 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 93e08f6..4b1cdc8 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -94,6 +94,47 @@
#define ACL_LEAD_CHAR ('@')
#define ROUTE_LEAD_CHAR('R')
#define COMMENT_LEAD_CHAR ('#')
+#define LPM_LEAD_CHAR ('L')
+#define EM_LEAD_CHAR ('E')
+
+#defineIPV6_ADDR_LEN 16
+#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
+#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
+
+#define GET_CB_FIELD(in, fd, base, lim, dlm) do {\
+ unsigned long val; \
+ char *end; \
+ errno = 0; \
+ val = strtoul((in), &end, (base)); \
+ if (errno != 0 || end[0] != (dlm) || val > (lim)) \
+ return -EINVAL; \
+ (fd) = (typeof(fd))val; \
+ (in) = end + 1; \
+} while (0)
+
+/* Bypass comment and empty lines */
+static inline int
+is_bypass_line(char *buff)
+{
+ int i = 0;
+
+ /* comment line */
+ if (buff[0] == COMMENT_LEAD_CHAR)
+ return 1;
+ /* empty line */
+ while (buff[i] != '\0') {
+ if (!isspace(buff[i]))
+ return 0;
+ i++;
+ }
+ return 1;
+}
+
+struct parm_cfg {
+ const char *rule_ipv4_name;
+ const char *rule_ipv6_name;
+ int scalar;
+};
struct mbuf_table {
uint16_t len;
@@ -134,6 +175,8 @@ extern xmm_t val_eth[RTE_MAX_ETHPORTS];
extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+extern struct parm_cfg parm_config;
+
extern int numa_on; /**< NUMA is enabled by default. */
/* Send burst of packets on an output interface */
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index 388b978..66ed23d 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -147,10 +147,6 @@ struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
},
};
-#defineIPV6_ADDR_LEN 16
-#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
-#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
-
enum {
PROTO_FIELD_IPV6,
SRC1_FIELD_IPV6,
@@ -297,12 +293,6 @@ static struct {
const char cb_port_delim[] = ":";
-static struct {
- const char *rule_ipv4_name;
- const char *rule_ipv6_name;
- int scalar;
-} parm_config;
-
/*
* Print and dump ACL/Route rules functions are defined in
* following header file.
@@ -316,27 +306,6 @@ static struct {
#include "l3fwd_acl_scalar.h"
/*
- * API's called during initialization to setup ACL rules.
- */
-void
-l3fwd_acl_set_rule_ipv4_name(const char *optarg)
-{
- parm_config.rule_ipv4_name = optarg;
-}
-
-void
-l3fwd_acl_set_rule_ipv6_name(const char *optarg)
-{
- parm_config.rule_ipv6_name = optarg;
-}
-
-void
-l3fwd_acl_set_scalar(void)
-{
- parm_config.scalar = 1;
-}
-
-/*
* Parses IPV6 address, exepcts the following format:
* ::::::: (where X - is a hexedecimal digit).
*/
@@ -566,7 +535,7 @@ parse_cb_ipv4vlan_rule(char *str, struct rte_acl_rule *v,
int has_userdata)
}
static int
-add_rules(const char *rule_path,
+acl_add_rules(const char *rule_path,
struct rte_acl_rule **proute_base,
unsigned int *proute_num,
struct rte_acl_rule **pacl_base,
@@ -764,8 +733,8 @@ setup_acl(const int socket
Re: [dpdk-dev] [RFC 17.05 v1 0/3] Merge l3fwd-acl and l3fwd
Hi Konstantin,
Sorry for this one, I had to resend patch series as 'v3' as additional
checkpatch warnings were seen after the submission which didn't show up in
my run.
'v3' patch should have all fixed except the ones I mentioned in my earlier
email on which I need inputs from you.
Thanks.
On Sat, Mar 4, 2017 at 11:49 AM, Ravi Kerur wrote:
> Hi Konstantin,
>
> I have sent 'v2' patchset. I need clarifications on following things, if
> they should be fixed I will send out 'v3' so please let me know.
>
> Following code changes were done by me manually, not merged.
> +++ b/examples/l3fwd/main.c
> @@ -161,7 +163,9 @@ static struct rte_eth_conf port_conf = {
> .rx_adv_conf = {
> .rss_conf = {
> .rss_key = NULL,
> - .rss_hf = ETH_RSS_IP,
> + .rss_hf = ETH_RSS_IP | ETH_RSS_UDP |
> + ETH_RSS_TCP | ETH_RSS_SCTP,
> +
> },
>
> The reason I did it is because
>
> LPM/EM has .rss_hf = ETH_RSS_IP
> ACL has .rss_hf = ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP | ETH_RSS_SCTP,
>
> ACL looks like a superset of LPM/EM and functional testing didn't reveal
> any issues hence I kept ACL version.
>
> 2. Checkpatch errors are all fixed. Some warnings are not fixed and they
> are
>
> 2.a, string length greater than 80 characters
> 2.b GET_CB_FIELD macro. I could have changed GET_CB_FIELD to inline
> function, however, function names cannot be in capital letters. I could
> have changed it to 'get_cb_field' inline function, but didn't do it as I
> thought it may not be worth the change.
>
> Let me know your inputs.
>
> Thanks.
>
> On Wed, Mar 1, 2017 at 7:29 AM, Ravi Kerur wrote:
>
>> Hi Konstantin,
>>
>> Thank you for the review.
>>
>> RSS hash value changes could be due to merge, I didn't make that change.
>> I will go through the changes and fix it in 'v2' patch along with RFC
>> removed and checkpatch fix.
>>
>> Thanks.
>>
>> On Tue, Feb 28, 2017 at 2:36 AM, Ananyev, Konstantin <
>> konstantin.anan...@intel.com> wrote:
>>
>>> Hi Ravi,
>>>
>>> >
>>> > Thanks to Konstantin and Bruce on first internal review comments. This
>>> > patch is RFC for 17.05 to merge l3fwd-acl and l3fwd code and add file
>>> > read options to build LPM and EM tables.
>>>
>>>
>>> Thanks for the patch, I think it is really useful one.
>>> Can I suggest you re-submit it as non-RFC now, as we are in 17.05 window
>>> already?
>>> About the patch itself, one question I forgot to ask you before:
>>>
>>> +++ b/examples/l3fwd/main.c
>>> @@ -161,7 +163,9 @@ static struct rte_eth_conf port_conf = {
>>> .rx_adv_conf = {
>>> .rss_conf = {
>>> .rss_key = NULL,
>>> - .rss_hf = ETH_RSS_IP,
>>> + .rss_hf = ETH_RSS_IP | ETH_RSS_UDP |
>>> + ETH_RSS_TCP | ETH_RSS_SCTP,
>>> +
>>> },
>>> },
>>>
>>>
>>> Why it is necessary to change RSS hash input values?
>>>
>>> As another nit - there are few checkpatch warnings, that probably need
>>> to be addressed.
>>> Apart from that looks good to me.
>>> Thanks
>>> Konstantin
>>>
>>>
>>>
>>
>
[dpdk-dev] [v3 3/3] EM config file read option.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings.
v1:
> Remove static array configuration of Dest IP,Src IP, Dest
port, Src port, Proto and IF_OUT for EM and EM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#EM route entries,
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
E101.0.0.0 100.10.0.0 101 11 0x06 0
E201.0.0.0 200.20.0.0 102 12 0x06 1
E111.0.0.0 211.30.0.0 101 11 0x06 2
...
#EM6 route entries
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
Efe80::::021e:67ff:fe00:
fe80::::021b:21ff:fe91:3805 101 11 0x06 0
Efe90::::021e:67ff:fe00:
fe90::::021b:21ff:fe91:3805 102 12 0x06 1
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd_em.c | 376 +-
1 file changed, 303 insertions(+), 73 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 6fdabf7..cd6b443 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -95,8 +95,14 @@ union ipv4_5tuple_host {
#define XMM_NUM_IN_IPV6_5TUPLE 3
struct ipv6_5tuple {
- uint8_t ip_dst[IPV6_ADDR_LEN];
- uint8_t ip_src[IPV6_ADDR_LEN];
+ union {
+ uint8_t ip_dst[IPV6_ADDR_LEN];
+ uint32_t ip32_dst[4];
+ };
+ union {
+ uint8_t ip_src[IPV6_ADDR_LEN];
+ uint32_t ip32_src[4];
+ };
uint16_t port_dst;
uint16_t port_src;
uint8_t proto;
@@ -116,47 +122,24 @@ union ipv6_5tuple_host {
xmm_t xmm[XMM_NUM_IN_IPV6_5TUPLE];
};
-
-
-struct ipv4_l3fwd_em_route {
- struct ipv4_5tuple key;
- uint8_t if_out;
+enum {
+ CB_FLD_DST_ADDR,
+ CB_FLD_SRC_ADDR,
+ CB_FLD_DST_PORT,
+ CB_FLD_SRC_PORT,
+ CB_FLD_PROTO,
+ CB_FLD_IF_OUT,
+ CB_FLD_MAX
};
-struct ipv6_l3fwd_em_route {
- struct ipv6_5tuple key;
+struct em_rule {
+ union {
+ struct ipv4_5tuple v4_key;
+ struct ipv6_5tuple v6_key;
+ };
uint8_t if_out;
};
-static struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
- {{IPv4(101, 0, 0, 0), IPv4(100, 10, 0, 1), 101, 11, IPPROTO_TCP}, 0},
- {{IPv4(201, 0, 0, 0), IPv4(200, 20, 0, 1), 102, 12, IPPROTO_TCP}, 1},
- {{IPv4(111, 0, 0, 0), IPv4(100, 30, 0, 1), 101, 11, IPPROTO_TCP}, 2},
- {{IPv4(211, 0, 0, 0), IPv4(200, 40, 0, 1), 102, 12, IPPROTO_TCP}, 3},
-};
-
-static struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
- {{
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 0},
-
- {{
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 1},
-
- {{
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 2},
-
- {{
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 3},
-};
-
struct rte_hash *ipv4_l3fwd_em_lookup_struct[NB_SOCKETS];
struct rte_hash *ipv6_l3fwd_em_lookup_struct[NB_SOCKETS];
@@ -233,12 +216,6 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t
data_len,
return init_val;
}
-#define IPV4_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv4_l3fwd_em_route_array) /
sizeof(ipv4_l3fwd_em_route_array[0]))
-
-#define IPV6_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv6_l3fwd_em_route_array) /
sizeof(ipv6_l3fwd_em_route_array[0]))
-
static uint8_t ipv4_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
static uint8_t ipv6_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
@@ -338,6 +315,224 @@ em_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid,
void *lookup_struct)
#include "l3fwd_em.h"
#endif
+static int
+em_parse_v6_addr(const char *in, const char **end, uint32_t v[IPV6_ADDR_U32],
+ char dlm)
+{
+ uint32_t addr[IPV6_ADDR_U16];
+
+ GET_CB_FIELD(in, addr[0], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[1], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[2], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[3], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[4], 16, U
[dpdk-dev] [v3 1/3] Merge l3fwd-acl and l3fwd code.
v3: > Fix additional checkpatch coding style issues. v2: > Fix checkpatch errors and warnings related to non strings greater than 80 characters. > MACRO GET_CB_FIELD and strings greater than 80 characters warnings are not fixed. v1: l3fwd-acl changes: > Merge common init code in l3fwd-acl and l3fwd into main.c. > Move non-critical inline functions to l3fwd_acl.h. > Move critial packet processing inline functions to l3fwd_acl_scalar.h > Move l3fwd-acl init code to l3fwd_acl.c. > Delete l3fwd-acl directory. l3fwd changes: > Add '-A' as an option for ACL processing. > Merge parsing options from l3fwd-acl and l3fwd. Retain l3fwd-acl definitions. > Move specific setup functions (setup_acl, setup_lpm and setup_hash). Testing: > Compiled successfully for x86_64-native-linuxapp-gcc > Tested LPM, EM and ACL basic functionality. Signed-off-by: Ravi Kerur --- examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 49 + examples/l3fwd/l3fwd_acl.c| 1064 +++ examples/l3fwd/l3fwd_acl.h| 263 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 14 +- examples/l3fwd/l3fwd_lpm.c| 23 +- examples/l3fwd/main.c | 208 ++-- 10 files changed, 1720 insertions(+), 2220 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile deleted file mode 100644 index a3473a8..000 --- a/examples/l3fwd-acl/Makefile +++ /dev/null @@ -1,56 +0,0 @@ -# BSD LICENSE -# -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of Intel Corporation nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -ifeq ($(RTE_SDK),) -$(error "Please define RTE_SDK environment variable") -endif - -# Default target, can be overriden by command line or environment -RTE_TARGET ?= x86_64-native-linuxapp-gcc - -include $(RTE_SDK)/mk/rte.vars.mk - -# binary name -APP = l3fwd-acl - -# all source are stored in SRCS-y -SRCS-y := main.c - -CFLAGS += -O3 -CFLAGS += $(WERROR_FLAGS) - -# workaround for a gcc bug with noreturn attribute -# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 -ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) -CFLAGS_main.o += -Wno-return-type -endif - -include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c deleted file mode 100644 index 3cfbb40..000 --- a/examples/l3fwd-acl/main.c +++ /dev/null @@ -1,2079 +0,0 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2010-2016 Intel Corporation. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - *
[dpdk-dev] [v3 2/3] LPM config file read option.
v3:
> Fix additional checkpatch coding style issues.
v2:
> Fix checkpatch warnings related to code
> MACRO GET_CB_FIELD checkpatch warning not fixed
v1:
> Remove static array configuration of Destination IP, MASK
and IF_OUT for LPM and LPM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#LPM route entries Dest-IP/Mask IF_OUT
L1.1.1.0/24 0
L2.1.1.0/24 1
L3.1.1.0/24 2
...
#LPM6 route entries Dest-IP/Mask IF_OUT
L:::::::/48 0
L2111:::::::/48 1
L3111:::::::/48 2
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd.h | 43 +++
examples/l3fwd/l3fwd_acl.c | 39 +-
examples/l3fwd/l3fwd_acl.h | 29 -
examples/l3fwd/l3fwd_lpm.c | 308 +
examples/l3fwd/main.c | 29 -
5 files changed, 329 insertions(+), 119 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 93e08f6..4b1cdc8 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -94,6 +94,47 @@
#define ACL_LEAD_CHAR ('@')
#define ROUTE_LEAD_CHAR('R')
#define COMMENT_LEAD_CHAR ('#')
+#define LPM_LEAD_CHAR ('L')
+#define EM_LEAD_CHAR ('E')
+
+#defineIPV6_ADDR_LEN 16
+#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
+#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
+
+#define GET_CB_FIELD(in, fd, base, lim, dlm) do {\
+ unsigned long val; \
+ char *end; \
+ errno = 0; \
+ val = strtoul((in), &end, (base)); \
+ if (errno != 0 || end[0] != (dlm) || val > (lim)) \
+ return -EINVAL; \
+ (fd) = (typeof(fd))val; \
+ (in) = end + 1; \
+} while (0)
+
+/* Bypass comment and empty lines */
+static inline int
+is_bypass_line(char *buff)
+{
+ int i = 0;
+
+ /* comment line */
+ if (buff[0] == COMMENT_LEAD_CHAR)
+ return 1;
+ /* empty line */
+ while (buff[i] != '\0') {
+ if (!isspace(buff[i]))
+ return 0;
+ i++;
+ }
+ return 1;
+}
+
+struct parm_cfg {
+ const char *rule_ipv4_name;
+ const char *rule_ipv6_name;
+ int scalar;
+};
struct mbuf_table {
uint16_t len;
@@ -134,6 +175,8 @@ extern xmm_t val_eth[RTE_MAX_ETHPORTS];
extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+extern struct parm_cfg parm_config;
+
extern int numa_on; /**< NUMA is enabled by default. */
/* Send burst of packets on an output interface */
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index 103c730..a5b2c12 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -147,10 +147,6 @@ struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
},
};
-#defineIPV6_ADDR_LEN 16
-#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
-#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
-
enum {
PROTO_FIELD_IPV6,
SRC1_FIELD_IPV6,
@@ -297,12 +293,6 @@ static struct {
const char cb_port_delim[] = ":";
-static struct {
- const char *rule_ipv4_name;
- const char *rule_ipv6_name;
- int scalar;
-} parm_config;
-
/*
* Print and dump ACL/Route rules functions are defined in
* following header file.
@@ -316,27 +306,6 @@ static struct {
#include "l3fwd_acl_scalar.h"
/*
- * API's called during initialization to setup ACL rules.
- */
-void
-l3fwd_acl_set_rule_ipv4_name(const char *optarg)
-{
- parm_config.rule_ipv4_name = optarg;
-}
-
-void
-l3fwd_acl_set_rule_ipv6_name(const char *optarg)
-{
- parm_config.rule_ipv6_name = optarg;
-}
-
-void
-l3fwd_acl_set_scalar(void)
-{
- parm_config.scalar = 1;
-}
-
-/*
* Parses IPV6 address, exepcts the following format:
* ::::::: (where X - is a hexedecimal digit).
*/
@@ -566,7 +535,7 @@ parse_cb_ipv4vlan_rule(char *str, struct rte_acl_rule *v,
int has_userdata)
}
static int
-add_rules(const char *rule_path,
+acl_add_rules(const char *rule_path,
struct rte_acl_rule **proute_base,
unsigned int *proute_num,
struct rte_acl_rule **pacl_base,
@@ -764,8 +733,8 @@ setup_acl(const int socket_id __attribut
[dpdk-dev] [v3 0/3] Merge l3fwd-acl and l3fwd
This patchset merges l3fwd-acl and l3fwd code into common directory. Adds file read options to build LPM and EM tables. Ravi Kerur (3): Merge l3fwd-acl and l3fwd code. LPM config file read option. EM config file read option. examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 92 ++ examples/l3fwd/l3fwd_acl.c| 1033 ++ examples/l3fwd/l3fwd_acl.h| 234 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 390 +-- examples/l3fwd/l3fwd_lpm.c| 323 -- examples/l3fwd/main.c | 231 +++-- 10 files changed, 2281 insertions(+), 2341 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h -- 2.7.4
[dpdk-dev] [v2 2/3] LPM config file read option
v2:
> Fix checkpatch warnings related to code
> MACRO GET_CB_FIELD checkpatch warning not fixed
v1:
> Remove static array configuration of Destination IP, MASK
and IF_OUT for LPM and LPM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#LPM route entries Dest-IP/Mask IF_OUT
L1.1.1.0/24 0
L2.1.1.0/24 1
L3.1.1.0/24 2
...
#LPM6 route entries Dest-IP/Mask IF_OUT
L:::::::/48 0
L2111:::::::/48 1
L3111:::::::/48 2
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd.h | 43 +++
examples/l3fwd/l3fwd_acl.c | 39 +-
examples/l3fwd/l3fwd_acl.h | 29 -
examples/l3fwd/l3fwd_lpm.c | 308 +
examples/l3fwd/main.c | 29 -
5 files changed, 329 insertions(+), 119 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 93e08f6..4b1cdc8 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -94,6 +94,47 @@
#define ACL_LEAD_CHAR ('@')
#define ROUTE_LEAD_CHAR('R')
#define COMMENT_LEAD_CHAR ('#')
+#define LPM_LEAD_CHAR ('L')
+#define EM_LEAD_CHAR ('E')
+
+#defineIPV6_ADDR_LEN 16
+#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
+#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
+
+#define GET_CB_FIELD(in, fd, base, lim, dlm) do {\
+ unsigned long val; \
+ char *end; \
+ errno = 0; \
+ val = strtoul((in), &end, (base)); \
+ if (errno != 0 || end[0] != (dlm) || val > (lim)) \
+ return -EINVAL; \
+ (fd) = (typeof(fd))val; \
+ (in) = end + 1; \
+} while (0)
+
+/* Bypass comment and empty lines */
+static inline int
+is_bypass_line(char *buff)
+{
+ int i = 0;
+
+ /* comment line */
+ if (buff[0] == COMMENT_LEAD_CHAR)
+ return 1;
+ /* empty line */
+ while (buff[i] != '\0') {
+ if (!isspace(buff[i]))
+ return 0;
+ i++;
+ }
+ return 1;
+}
+
+struct parm_cfg {
+ const char *rule_ipv4_name;
+ const char *rule_ipv6_name;
+ int scalar;
+};
struct mbuf_table {
uint16_t len;
@@ -134,6 +175,8 @@ extern xmm_t val_eth[RTE_MAX_ETHPORTS];
extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+extern struct parm_cfg parm_config;
+
extern int numa_on; /**< NUMA is enabled by default. */
/* Send burst of packets on an output interface */
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index ff34264..f201dae 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -147,10 +147,6 @@ struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
},
};
-#defineIPV6_ADDR_LEN 16
-#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
-#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
-
enum {
PROTO_FIELD_IPV6,
SRC1_FIELD_IPV6,
@@ -297,12 +293,6 @@ static struct {
const char cb_port_delim[] = ":";
-static struct {
- const char *rule_ipv4_name;
- const char *rule_ipv6_name;
- int scalar;
-} parm_config;
-
/*
* Print and dump ACL/Route rules functions are defined in
* following header file.
@@ -316,27 +306,6 @@ static struct {
#include "l3fwd_acl_scalar.h"
/*
- * API's called during initialization to setup ACL rules.
- */
-void
-l3fwd_acl_set_rule_ipv4_name(const char *optarg)
-{
- parm_config.rule_ipv4_name = optarg;
-}
-
-void
-l3fwd_acl_set_rule_ipv6_name(const char *optarg)
-{
- parm_config.rule_ipv6_name = optarg;
-}
-
-void
-l3fwd_acl_set_scalar(void)
-{
- parm_config.scalar = 1;
-}
-
-/*
* Parses IPV6 address, exepcts the following format:
* ::::::: (where X - is a hexedecimal digit).
*/
@@ -566,7 +535,7 @@ parse_cb_ipv4vlan_rule(char *str, struct rte_acl_rule *v,
int has_userdata)
}
static int
-add_rules(const char *rule_path,
+acl_add_rules(const char *rule_path,
struct rte_acl_rule **proute_base,
unsigned int *proute_num,
struct rte_acl_rule **pacl_base,
@@ -764,8 +733,8 @@ setup_acl(const int socket_id __attribute__((unused)))
dump_acl_config();
- /* Load rules from the in
[dpdk-dev] [v2 1/3] Merge l3fwd-acl and l3fwd
v2: > Fix checkpatch errors and warnings related to non strings greater than 80 characters. > MACRO GET_CB_FIELD and strings greater than 80 characters warnings are not fixed. v1: l3fwd-acl changes: > Merge common init code in l3fwd-acl and l3fwd into main.c. > Move non-critical inline functions to l3fwd_acl.h. > Move critial packet processing inline functions to l3fwd_acl_scalar.h > Move l3fwd-acl init code to l3fwd_acl.c. > Delete l3fwd-acl directory. l3fwd changes: > Add '-A' as an option for ACL processing. > Merge parsing options from l3fwd-acl and l3fwd. Retain l3fwd-acl definitions. > Move specific setup functions (setup_acl, setup_lpm and setup_hash). Testing: Compiled successfully for x86_64-native-linuxapp-gcc Tested LPM, EM and ACL basic functionality. Signed-off-by: Ravi Kerur --- examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 49 + examples/l3fwd/l3fwd_acl.c| 1064 +++ examples/l3fwd/l3fwd_acl.h| 263 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 14 +- examples/l3fwd/l3fwd_lpm.c| 23 +- examples/l3fwd/main.c | 208 ++-- 10 files changed, 1720 insertions(+), 2220 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile deleted file mode 100644 index a3473a8..000 --- a/examples/l3fwd-acl/Makefile +++ /dev/null @@ -1,56 +0,0 @@ -# BSD LICENSE -# -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of Intel Corporation nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -ifeq ($(RTE_SDK),) -$(error "Please define RTE_SDK environment variable") -endif - -# Default target, can be overriden by command line or environment -RTE_TARGET ?= x86_64-native-linuxapp-gcc - -include $(RTE_SDK)/mk/rte.vars.mk - -# binary name -APP = l3fwd-acl - -# all source are stored in SRCS-y -SRCS-y := main.c - -CFLAGS += -O3 -CFLAGS += $(WERROR_FLAGS) - -# workaround for a gcc bug with noreturn attribute -# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 -ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) -CFLAGS_main.o += -Wno-return-type -endif - -include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c deleted file mode 100644 index 3cfbb40..000 --- a/examples/l3fwd-acl/main.c +++ /dev/null @@ -1,2079 +0,0 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2010-2016 Intel Corporation. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above
[dpdk-dev] [v2 3/3] EM config file read option
v2:
> Fix checkpatch warnings.
v1:
> Remove static array configuration of Dest IP,Src IP, Dest
port, Src port, Proto and IF_OUT for EM and EM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#EM route entries,
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
E101.0.0.0 100.10.0.0 101 11 0x06 0
E201.0.0.0 200.20.0.0 102 12 0x06 1
E111.0.0.0 211.30.0.0 101 11 0x06 2
...
#EM6 route entries
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
Efe80::::021e:67ff:fe00:
fe80::::021b:21ff:fe91:3805 101 11 0x06 0
Efe90::::021e:67ff:fe00:
fe90::::021b:21ff:fe91:3805 102 12 0x06 1
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd_em.c | 376 +-
1 file changed, 303 insertions(+), 73 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 6fdabf7..74f5e80 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -95,8 +95,14 @@ union ipv4_5tuple_host {
#define XMM_NUM_IN_IPV6_5TUPLE 3
struct ipv6_5tuple {
- uint8_t ip_dst[IPV6_ADDR_LEN];
- uint8_t ip_src[IPV6_ADDR_LEN];
+ union {
+ uint8_t ip_dst[IPV6_ADDR_LEN];
+ uint32_t ip32_dst[4];
+ };
+ union {
+ uint8_t ip_src[IPV6_ADDR_LEN];
+ uint32_t ip32_src[4];
+ };
uint16_t port_dst;
uint16_t port_src;
uint8_t proto;
@@ -116,47 +122,24 @@ union ipv6_5tuple_host {
xmm_t xmm[XMM_NUM_IN_IPV6_5TUPLE];
};
-
-
-struct ipv4_l3fwd_em_route {
- struct ipv4_5tuple key;
- uint8_t if_out;
+enum {
+ CB_FLD_DST_ADDR,
+ CB_FLD_SRC_ADDR,
+ CB_FLD_DST_PORT,
+ CB_FLD_SRC_PORT,
+ CB_FLD_PROTO,
+ CB_FLD_IF_OUT,
+ CB_FLD_MAX
};
-struct ipv6_l3fwd_em_route {
- struct ipv6_5tuple key;
+struct em_rule {
+ union {
+ struct ipv4_5tuple v4_key;
+ struct ipv6_5tuple v6_key;
+ };
uint8_t if_out;
};
-static struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
- {{IPv4(101, 0, 0, 0), IPv4(100, 10, 0, 1), 101, 11, IPPROTO_TCP}, 0},
- {{IPv4(201, 0, 0, 0), IPv4(200, 20, 0, 1), 102, 12, IPPROTO_TCP}, 1},
- {{IPv4(111, 0, 0, 0), IPv4(100, 30, 0, 1), 101, 11, IPPROTO_TCP}, 2},
- {{IPv4(211, 0, 0, 0), IPv4(200, 40, 0, 1), 102, 12, IPPROTO_TCP}, 3},
-};
-
-static struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
- {{
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 0},
-
- {{
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 1},
-
- {{
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 2},
-
- {{
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 3},
-};
-
struct rte_hash *ipv4_l3fwd_em_lookup_struct[NB_SOCKETS];
struct rte_hash *ipv6_l3fwd_em_lookup_struct[NB_SOCKETS];
@@ -233,12 +216,6 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t
data_len,
return init_val;
}
-#define IPV4_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv4_l3fwd_em_route_array) /
sizeof(ipv4_l3fwd_em_route_array[0]))
-
-#define IPV6_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv6_l3fwd_em_route_array) /
sizeof(ipv6_l3fwd_em_route_array[0]))
-
static uint8_t ipv4_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
static uint8_t ipv6_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
@@ -338,6 +315,224 @@ em_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid,
void *lookup_struct)
#include "l3fwd_em.h"
#endif
+static int
+em_parse_v6_addr(const char *in, const char **end, uint32_t v[IPV6_ADDR_U32],
+ char dlm)
+{
+ uint32_t addr[IPV6_ADDR_U16];
+
+ GET_CB_FIELD(in, addr[0], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[1], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[2], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[3], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[4], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[5]
[dpdk-dev] [v2 0/3] Merge l3fwd-acl and l3fwd
This patchset merges l3fwd-acl and l3fwd code into common directory. Add file read options to build LPM and EM tables. Ravi Kerur (3): Merge l3fwd-acl and l3fwd LPM config file read option EM config file read option examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 92 ++ examples/l3fwd/l3fwd_acl.c| 1033 ++ examples/l3fwd/l3fwd_acl.h| 234 + examples/l3fwd/l3fwd_acl_scalar.h | 182 examples/l3fwd/l3fwd_em.c | 390 +-- examples/l3fwd/l3fwd_lpm.c| 323 -- examples/l3fwd/main.c | 231 +++-- 10 files changed, 2281 insertions(+), 2341 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h -- 2.7.4
Re: [dpdk-dev] [RFC 17.05 v1 0/3] Merge l3fwd-acl and l3fwd
Hi Konstantin,
I have sent 'v2' patchset. I need clarifications on following things, if
they should be fixed I will send out 'v3' so please let me know.
Following code changes were done by me manually, not merged.
+++ b/examples/l3fwd/main.c
@@ -161,7 +163,9 @@ static struct rte_eth_conf port_conf = {
.rx_adv_conf = {
.rss_conf = {
.rss_key = NULL,
- .rss_hf = ETH_RSS_IP,
+ .rss_hf = ETH_RSS_IP | ETH_RSS_UDP |
+ ETH_RSS_TCP | ETH_RSS_SCTP,
+
},
The reason I did it is because
LPM/EM has .rss_hf = ETH_RSS_IP
ACL has .rss_hf = ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP | ETH_RSS_SCTP,
ACL looks like a superset of LPM/EM and functional testing didn't reveal
any issues hence I kept ACL version.
2. Checkpatch errors are all fixed. Some warnings are not fixed and they are
2.a, string length greater than 80 characters
2.b GET_CB_FIELD macro. I could have changed GET_CB_FIELD to inline
function, however, function names cannot be in capital letters. I could
have changed it to 'get_cb_field' inline function, but didn't do it as I
thought it may not be worth the change.
Let me know your inputs.
Thanks.
On Wed, Mar 1, 2017 at 7:29 AM, Ravi Kerur wrote:
> Hi Konstantin,
>
> Thank you for the review.
>
> RSS hash value changes could be due to merge, I didn't make that change. I
> will go through the changes and fix it in 'v2' patch along with RFC removed
> and checkpatch fix.
>
> Thanks.
>
> On Tue, Feb 28, 2017 at 2:36 AM, Ananyev, Konstantin <
> konstantin.anan...@intel.com> wrote:
>
>> Hi Ravi,
>>
>> >
>> > Thanks to Konstantin and Bruce on first internal review comments. This
>> > patch is RFC for 17.05 to merge l3fwd-acl and l3fwd code and add file
>> > read options to build LPM and EM tables.
>>
>>
>> Thanks for the patch, I think it is really useful one.
>> Can I suggest you re-submit it as non-RFC now, as we are in 17.05 window
>> already?
>> About the patch itself, one question I forgot to ask you before:
>>
>> +++ b/examples/l3fwd/main.c
>> @@ -161,7 +163,9 @@ static struct rte_eth_conf port_conf = {
>> .rx_adv_conf = {
>> .rss_conf = {
>> .rss_key = NULL,
>> - .rss_hf = ETH_RSS_IP,
>> + .rss_hf = ETH_RSS_IP | ETH_RSS_UDP |
>> + ETH_RSS_TCP | ETH_RSS_SCTP,
>> +
>> },
>> },
>>
>>
>> Why it is necessary to change RSS hash input values?
>>
>> As another nit - there are few checkpatch warnings, that probably need
>> to be addressed.
>> Apart from that looks good to me.
>> Thanks
>> Konstantin
>>
>>
>>
>
Re: [dpdk-dev] [RFC 17.05 v1 0/3] Merge l3fwd-acl and l3fwd
Hi Konstantin,
Thank you for the review.
RSS hash value changes could be due to merge, I didn't make that change. I
will go through the changes and fix it in 'v2' patch along with RFC removed
and checkpatch fix.
Thanks.
On Tue, Feb 28, 2017 at 2:36 AM, Ananyev, Konstantin <
konstantin.anan...@intel.com> wrote:
> Hi Ravi,
>
> >
> > Thanks to Konstantin and Bruce on first internal review comments. This
> > patch is RFC for 17.05 to merge l3fwd-acl and l3fwd code and add file
> > read options to build LPM and EM tables.
>
>
> Thanks for the patch, I think it is really useful one.
> Can I suggest you re-submit it as non-RFC now, as we are in 17.05 window
> already?
> About the patch itself, one question I forgot to ask you before:
>
> +++ b/examples/l3fwd/main.c
> @@ -161,7 +163,9 @@ static struct rte_eth_conf port_conf = {
> .rx_adv_conf = {
> .rss_conf = {
> .rss_key = NULL,
> - .rss_hf = ETH_RSS_IP,
> + .rss_hf = ETH_RSS_IP | ETH_RSS_UDP |
> + ETH_RSS_TCP | ETH_RSS_SCTP,
> +
> },
> },
>
>
> Why it is necessary to change RSS hash input values?
>
> As another nit - there are few checkpatch warnings, that probably need
> to be addressed.
> Apart from that looks good to me.
> Thanks
> Konstantin
>
>
>
[dpdk-dev] [RFC 17.05 v1 1/3] Merge l3fwd-acl and l3fwd
v1: l3fwd-acl changes: > Merge common init code in l3fwd-acl and l3fwd into main.c. > Move non-critical inline functions to l3fwd_acl.h. > Move critial packet processing inline functions to l3fwd_acl_scalar.h > Move l3fwd-acl init code to l3fwd_acl.c. > Delete l3fwd-acl directory. l3fwd changes: > Add '-A' as an option for ACL processing. > Merge parsing options from l3fwd-acl and l3fwd. Retain l3fwd-acl definitions. > Move specific setup functions (setup_acl, setup_lpm and setup_hash). Testing: Compiled successfully for x86_64-native-linuxapp-gcc Tested LPM, EM and ACL basic functionality. Signed-off-by: Ravi Kerur --- examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 49 + examples/l3fwd/l3fwd_acl.c| 1060 +++ examples/l3fwd/l3fwd_acl.h| 263 + examples/l3fwd/l3fwd_acl_scalar.h | 181 examples/l3fwd/l3fwd_em.c | 14 +- examples/l3fwd/l3fwd_lpm.c| 23 +- examples/l3fwd/main.c | 208 ++-- 10 files changed, 1715 insertions(+), 2220 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile deleted file mode 100644 index a3473a8..000 --- a/examples/l3fwd-acl/Makefile +++ /dev/null @@ -1,56 +0,0 @@ -# BSD LICENSE -# -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of Intel Corporation nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -ifeq ($(RTE_SDK),) -$(error "Please define RTE_SDK environment variable") -endif - -# Default target, can be overriden by command line or environment -RTE_TARGET ?= x86_64-native-linuxapp-gcc - -include $(RTE_SDK)/mk/rte.vars.mk - -# binary name -APP = l3fwd-acl - -# all source are stored in SRCS-y -SRCS-y := main.c - -CFLAGS += -O3 -CFLAGS += $(WERROR_FLAGS) - -# workaround for a gcc bug with noreturn attribute -# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 -ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) -CFLAGS_main.o += -Wno-return-type -endif - -include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c deleted file mode 100644 index 3cfbb40..000 --- a/examples/l3fwd-acl/main.c +++ /dev/null @@ -1,2079 +0,0 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2010-2016 Intel Corporation. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer
[dpdk-dev] [RFC 17.05 v1 3/3] EM config file read option
v1:
> Remove static array configuration of Dest IP,Src IP, Dest
port, Src port, Proto and IF_OUT for EM and EM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#EM route entries,
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
E101.0.0.0 100.10.0.0 101 11 0x06 0
E201.0.0.0 200.20.0.0 102 12 0x06 1
E111.0.0.0 211.30.0.0 101 11 0x06 2
...
#EM6 route entries
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
Efe80::::021e:67ff:fe00:
fe80::::021b:21ff:fe91:3805 101 11 0x06 0
Efe90::::021e:67ff:fe00:
fe90::::021b:21ff:fe91:3805 102 12 0x06 1
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd_em.c | 376 +-
1 file changed, 303 insertions(+), 73 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 6fdabf7..3528947 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -95,8 +95,14 @@ union ipv4_5tuple_host {
#define XMM_NUM_IN_IPV6_5TUPLE 3
struct ipv6_5tuple {
- uint8_t ip_dst[IPV6_ADDR_LEN];
- uint8_t ip_src[IPV6_ADDR_LEN];
+ union {
+ uint8_t ip_dst[IPV6_ADDR_LEN];
+ uint32_t ip32_dst[4];
+ };
+ union {
+ uint8_t ip_src[IPV6_ADDR_LEN];
+ uint32_t ip32_src[4];
+ };
uint16_t port_dst;
uint16_t port_src;
uint8_t proto;
@@ -116,47 +122,24 @@ union ipv6_5tuple_host {
xmm_t xmm[XMM_NUM_IN_IPV6_5TUPLE];
};
-
-
-struct ipv4_l3fwd_em_route {
- struct ipv4_5tuple key;
- uint8_t if_out;
+enum {
+ CB_FLD_DST_ADDR,
+ CB_FLD_SRC_ADDR,
+ CB_FLD_DST_PORT,
+ CB_FLD_SRC_PORT,
+ CB_FLD_PROTO,
+ CB_FLD_IF_OUT,
+ CB_FLD_MAX
};
-struct ipv6_l3fwd_em_route {
- struct ipv6_5tuple key;
+struct em_rule {
+ union {
+ struct ipv4_5tuple v4_key;
+ struct ipv6_5tuple v6_key;
+ };
uint8_t if_out;
};
-static struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
- {{IPv4(101, 0, 0, 0), IPv4(100, 10, 0, 1), 101, 11, IPPROTO_TCP}, 0},
- {{IPv4(201, 0, 0, 0), IPv4(200, 20, 0, 1), 102, 12, IPPROTO_TCP}, 1},
- {{IPv4(111, 0, 0, 0), IPv4(100, 30, 0, 1), 101, 11, IPPROTO_TCP}, 2},
- {{IPv4(211, 0, 0, 0), IPv4(200, 40, 0, 1), 102, 12, IPPROTO_TCP}, 3},
-};
-
-static struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
- {{
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 0},
-
- {{
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 1},
-
- {{
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 2},
-
- {{
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 3},
-};
-
struct rte_hash *ipv4_l3fwd_em_lookup_struct[NB_SOCKETS];
struct rte_hash *ipv6_l3fwd_em_lookup_struct[NB_SOCKETS];
@@ -233,12 +216,6 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t
data_len,
return init_val;
}
-#define IPV4_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv4_l3fwd_em_route_array) /
sizeof(ipv4_l3fwd_em_route_array[0]))
-
-#define IPV6_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv6_l3fwd_em_route_array) /
sizeof(ipv6_l3fwd_em_route_array[0]))
-
static uint8_t ipv4_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
static uint8_t ipv6_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
@@ -338,6 +315,224 @@ em_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid,
void *lookup_struct)
#include "l3fwd_em.h"
#endif
+static int
+em_parse_v6_addr(const char *in, const char **end, uint32_t v[IPV6_ADDR_U32],
+ char dlm)
+{
+ uint32_t addr[IPV6_ADDR_U16];
+
+ GET_CB_FIELD(in, addr[0], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[1], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[2], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[3], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[4], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[5], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[
[dpdk-dev] [RFC 17.05 v1 0/3] Merge l3fwd-acl and l3fwd
Thanks to Konstantin and Bruce on first internal review comments. This patch is RFC for 17.05 to merge l3fwd-acl and l3fwd code and add file read options to build LPM and EM tables. Ravi Kerur (3): Merge l3fwd-acl and l3fwd LPM config file read option EM config file read option examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 92 ++ examples/l3fwd/l3fwd_acl.c| 1029 ++ examples/l3fwd/l3fwd_acl.h| 234 + examples/l3fwd/l3fwd_acl_scalar.h | 181 examples/l3fwd/l3fwd_em.c | 390 +-- examples/l3fwd/l3fwd_lpm.c| 322 -- examples/l3fwd/main.c | 231 +++-- 10 files changed, 2275 insertions(+), 2341 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h -- 2.7.4
[dpdk-dev] [RFC 17.05 v1 2/3] LPM config file read option
v1:
> Remove static array configuration of Destination IP, MASK
and IF_OUT for LPM and LPM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#LPM route entries Dest-IP/Mask IF_OUT
L1.1.1.0/24 0
L2.1.1.0/24 1
L3.1.1.0/24 2
...
#LPM6 route entries Dest-IP/Mask IF_OUT
L:::::::/48 0
L2111:::::::/48 1
L3111:::::::/48 2
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd.h | 43 +++
examples/l3fwd/l3fwd_acl.c | 39 +-
examples/l3fwd/l3fwd_acl.h | 29 -
examples/l3fwd/l3fwd_lpm.c | 307 +
examples/l3fwd/main.c | 29 -
5 files changed, 328 insertions(+), 119 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 93e08f6..4b1cdc8 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -94,6 +94,47 @@
#define ACL_LEAD_CHAR ('@')
#define ROUTE_LEAD_CHAR('R')
#define COMMENT_LEAD_CHAR ('#')
+#define LPM_LEAD_CHAR ('L')
+#define EM_LEAD_CHAR ('E')
+
+#defineIPV6_ADDR_LEN 16
+#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
+#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
+
+#define GET_CB_FIELD(in, fd, base, lim, dlm) do {\
+ unsigned long val; \
+ char *end; \
+ errno = 0; \
+ val = strtoul((in), &end, (base)); \
+ if (errno != 0 || end[0] != (dlm) || val > (lim)) \
+ return -EINVAL; \
+ (fd) = (typeof(fd))val; \
+ (in) = end + 1; \
+} while (0)
+
+/* Bypass comment and empty lines */
+static inline int
+is_bypass_line(char *buff)
+{
+ int i = 0;
+
+ /* comment line */
+ if (buff[0] == COMMENT_LEAD_CHAR)
+ return 1;
+ /* empty line */
+ while (buff[i] != '\0') {
+ if (!isspace(buff[i]))
+ return 0;
+ i++;
+ }
+ return 1;
+}
+
+struct parm_cfg {
+ const char *rule_ipv4_name;
+ const char *rule_ipv6_name;
+ int scalar;
+};
struct mbuf_table {
uint16_t len;
@@ -134,6 +175,8 @@ extern xmm_t val_eth[RTE_MAX_ETHPORTS];
extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+extern struct parm_cfg parm_config;
+
extern int numa_on; /**< NUMA is enabled by default. */
/* Send burst of packets on an output interface */
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index 977ca05..d6b15d6 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -147,10 +147,6 @@ struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
},
};
-#defineIPV6_ADDR_LEN 16
-#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
-#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
-
enum {
PROTO_FIELD_IPV6,
SRC1_FIELD_IPV6,
@@ -297,12 +293,6 @@ static struct {
const char cb_port_delim[] = ":";
-static struct {
- const char *rule_ipv4_name;
- const char *rule_ipv6_name;
- int scalar;
-} parm_config;
-
/*
* Print and dump ACL/Route rules functions are defined in
* following header file.
@@ -316,27 +306,6 @@ static struct {
#include "l3fwd_acl_scalar.h"
/*
- * API's called during initialization to setup ACL rules.
- */
-void
-l3fwd_acl_set_rule_ipv4_name(const char *optarg)
-{
- parm_config.rule_ipv4_name = optarg;
-}
-
-void
-l3fwd_acl_set_rule_ipv6_name(const char *optarg)
-{
- parm_config.rule_ipv6_name = optarg;
-}
-
-void
-l3fwd_acl_set_scalar(void)
-{
- parm_config.scalar = 1;
-}
-
-/*
* Parses IPV6 address, exepcts the following format:
* ::::::: (where X - is a hexedecimal digit).
*/
@@ -566,7 +535,7 @@ parse_cb_ipv4vlan_rule(char *str, struct rte_acl_rule *v,
int has_userdata)
}
static int
-add_rules(const char *rule_path,
+acl_add_rules(const char *rule_path,
struct rte_acl_rule **proute_base,
unsigned int *proute_num,
struct rte_acl_rule **pacl_base,
@@ -762,8 +731,8 @@ setup_acl(const int socket_id __attribute__((unused)))
dump_acl_config();
- /* Load rules from the input file */
- if (add_rules(parm_config.rule_ipv4_name, &route_base_ipv4,
+
[dpdk-dev] [PATCH v1 2/2] Test cases for rte_memcmp functions
Zhilong, Thomas,
If there is enough interest within DPDK community I can work on adding
support for 'unaligned access' and 'test cases' for it. Please let me know
either way.
Thanks,
Ravi
On Thu, May 26, 2016 at 2:05 AM, Wang, Zhihong
wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Kerur
> > Sent: Tuesday, March 8, 2016 7:01 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v1 2/2] Test cases for rte_memcmp functions
> >
> > v1:
> > This patch adds test cases for rte_memcmp functions.
> > New rte_memcmp functions can be tested via 'make test'
> > and 'testpmd' utility.
> >
> > Compiled and tested on Ubuntu 14.04(non-NUMA) and
> > 15.10(NUMA) systems.
> [...]
>
> > +/
> > ***
> > + * Memcmp function performance test configuration section. Each
> performance
> > test
> > + * will be performed MEMCMP_ITERATIONS times.
> > + *
> > + * The five arrays below control what tests are performed. Every
> combination
> > + * from the array entries is tested.
> > + */
> > +#define MEMCMP_ITERATIONS (500 * 500 * 500)
>
>
> Maybe less iteration will make the test faster without compromise precison?
>
>
> > +
> > +static size_t memcmp_sizes[] = {
> > + 2, 5, 8, 9, 15, 16, 17, 31, 32, 33, 63, 64, 65, 127, 128,
> > + 129, 191, 192, 193, 255, 256, 257, 319, 320, 321, 383, 384,
> > + 385, 447, 448, 449, 511, 512, 513, 767, 768, 769, 1023, 1024,
> > + 1025, 1522, 1536, 1600, 2048, 2560, 3072, 3584, 4096, 4608,
> > + 5632, 6144, 6656, 7168, 7680, 8192, 16834
> > +};
> > +
> [...]
> > +/*
> > + * Do all performance tests.
> > + */
> > +static int
> > +test_memcmp_perf(void)
> > +{
> > + if (run_all_memcmp_eq_perf_tests() != 0)
> > + return -1;
> > +
> > + if (run_all_memcmp_gt_perf_tests() != 0)
> > + return -1;
> > +
> > + if (run_all_memcmp_lt_perf_tests() != 0)
> > + return -1;
> > +
>
>
> Perhaps unaligned test cases are needed here.
> How do you think?
>
>
> > +
> > + return 0;
> > +}
> > +
> > +static struct test_command memcmp_perf_cmd = {
> > + .command = "memcmp_perf_autotest",
> > + .callback = test_memcmp_perf,
> > +};
> > +REGISTER_TEST_COMMAND(memcmp_perf_cmd);
> > --
> > 1.9.1
>
>
[dpdk-dev] [PATCH v1 2/2] Test cases for rte_memcmp functions
v1:
This patch adds test cases for rte_memcmp functions.
New rte_memcmp functions can be tested via 'make test'
and 'testpmd' utility.
Compiled and tested on Ubuntu 14.04(non-NUMA) and
15.10(NUMA) systems.
Signed-off-by: Ravi Kerur
---
app/test/Makefile | 31 +++-
app/test/autotest_data.py | 19 +++
app/test/test_memcmp.c | 250
app/test/test_memcmp_perf.c | 396
4 files changed, 695 insertions(+), 1 deletion(-)
create mode 100644 app/test/test_memcmp.c
create mode 100644 app/test/test_memcmp_perf.c
diff --git a/app/test/Makefile b/app/test/Makefile
index ec33e1a..f6ecaa9 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -82,6 +82,9 @@ SRCS-y += test_logs.c
SRCS-y += test_memcpy.c
SRCS-y += test_memcpy_perf.c
+SRCS-y += test_memcmp.c
+SRCS-y += test_memcmp_perf.c
+
SRCS-$(CONFIG_RTE_LIBRTE_HASH) += test_hash.c
SRCS-$(CONFIG_RTE_LIBRTE_HASH) += test_thash.c
SRCS-$(CONFIG_RTE_LIBRTE_HASH) += test_hash_perf.c
@@ -160,14 +163,40 @@ CFLAGS += $(WERROR_FLAGS)
CFLAGS += -D_GNU_SOURCE
-# Disable VTA for memcpy test
+# Disable VTA for memcpy and memcmp tests
ifeq ($(CC), gcc)
ifeq ($(shell test $(GCC_VERSION) -ge 44 && echo 1), 1)
CFLAGS_test_memcpy.o += -fno-var-tracking-assignments
CFLAGS_test_memcpy_perf.o += -fno-var-tracking-assignments
+
+CFLAGS_test_memcmp.o += -fno-var-tracking-assignments
+CFLAGS_test_memcmp_perf.o += -fno-var-tracking-assignments
+
endif
endif
+CMP_AVX2_SUPPORT=$(shell $(CC) -march=core-avx2 -dM -E - &1 | \
+ grep -q AVX2 && echo 1)
+
+ifeq ($(CMP_AVX2_SUPPORT), 1)
+ ifeq ($(CC), icc)
+ CFLAGS_test_memcmp.o += -march=core-avx2
+ CFLAGS_test_memcmp_perf.o += -march=core-avx2
+ else
+ CFLAGS_test_memcmp.o += -mavx2
+ CFLAGS_test_memcmp_perf.o += -mavx2
+ endif
+else
+ ifeq ($(CC), icc)
+ CFLAGS_test_memcmp.o += -march=core-sse4.1
+ CFLAGS_test_memcmp_perf.o += -march=core-sse4.1
+ else
+ CFLAGS_test_memcmp.o += -msse4.1
+ CFLAGS_test_memcmp_perf.o += -msse4.1
+ endif
+endif
+
+
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test/autotest_data.py b/app/test/autotest_data.py
index 6f34d6b..5113327 100644
--- a/app/test/autotest_data.py
+++ b/app/test/autotest_data.py
@@ -186,6 +186,12 @@ parallel_test_group_list = [
"Report" : None,
},
{
+"Name" : "Memcmp autotest",
+"Command" :"memcmp_autotest",
+"Func" : default_autotest,
+"Report" : None,
+ },
+ {
"Name" : "Memzone autotest",
"Command" :"memzone_autotest",
"Func" : default_autotest,
@@ -398,6 +404,19 @@ non_parallel_test_group_list = [
]
},
{
+ "Prefix": "memcmp_perf",
+ "Memory" : per_sockets(512),
+ "Tests" :
+ [
+ {
+"Name" : "Memcmp performance autotest",
+"Command" :"memcmp_perf_autotest",
+"Func" : default_autotest,
+"Report" : None,
+ },
+ ]
+},
+{
"Prefix": "hash_perf",
"Memory" : per_sockets(512),
"Tests" :
diff --git a/app/test/test_memcmp.c b/app/test/test_memcmp.c
new file mode 100644
index 000..e3b0bf7
--- /dev/null
+++ b/app/test/test_memcmp.c
@@ -0,0 +1,250 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND
[dpdk-dev] [PATCH v1 1/2] rte_memcmp functions using Intel AVX and SSE intrinsics
v1:
This patch adds memcmp functionality using AVX and SSE
intrinsics provided by Intel. For other architectures
supported by DPDK regular memcmp function is used.
Compiled and tested on Ubuntu 14.04(non-NUMA) and 15.10(NUMA)
systems.
Signed-off-by: Ravi Kerur
---
.../common/include/arch/arm/rte_memcmp.h | 60 ++
.../common/include/arch/ppc_64/rte_memcmp.h| 62 ++
.../common/include/arch/tile/rte_memcmp.h | 60 ++
.../common/include/arch/x86/rte_memcmp.h | 786 +
lib/librte_eal/common/include/generic/rte_memcmp.h | 175 +
5 files changed, 1143 insertions(+)
create mode 100644 lib/librte_eal/common/include/arch/arm/rte_memcmp.h
create mode 100644 lib/librte_eal/common/include/arch/ppc_64/rte_memcmp.h
create mode 100644 lib/librte_eal/common/include/arch/tile/rte_memcmp.h
create mode 100644 lib/librte_eal/common/include/arch/x86/rte_memcmp.h
create mode 100644 lib/librte_eal/common/include/generic/rte_memcmp.h
diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcmp.h
b/lib/librte_eal/common/include/arch/arm/rte_memcmp.h
new file mode 100644
index 000..fcbacb4
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/arm/rte_memcmp.h
@@ -0,0 +1,60 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 RehiveTech. 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 IBM Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef _RTE_MEMCMP_ARM_H_
+#define _RTE_MEMCMP_ARM_H_
+
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_memcmp.h"
+
+#define rte_memcmp(dst, src, n) \
+ ({ (__builtin_constant_p(n)) ? \
+ memcmp((dst), (src), (n)) : \
+ rte_memcmp_func((dst), (src), (n)); })
+
+static inline bool
+rte_memcmp_func(void *dst, const void *src, size_t n)
+{
+ return memcmp(dst, src, n);
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_MEMCMP_ARM_H_ */
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_memcmp.h
b/lib/librte_eal/common/include/arch/ppc_64/rte_memcmp.h
new file mode 100644
index 000..5839a2d
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcmp.h
@@ -0,0 +1,62 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright (C) IBM Corporation 2016.
+ *
+ * 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 IBM Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIA
[dpdk-dev] [PATCH v1 0/2] rte_memcmp functions
9.8415 *** *** 4096, 230.2136 *** *** 8192, 366.2912 *** *** 16384, 647.0217 *** *** RTE memcmp less than performance test results *** *** Length (bytes), Ticks/Op. *** *** 1,22.6627 *** *** 8,26.2665 *** *** 15,26.8192 *** *** 16,21.7960 *** *** 32,23.9878 *** *** 64,24.2074 *** ***128,26.8111 *** ***256,28.3444 *** ***512,34.7882 *** *** 1024,44.4824 *** *** 2048,63.4154 *** *** 4096, 101.4360 *** *** 8192, 179.1029 *** *** 16384, 333.9357 *** *** memcmp less than performance test results *** *** Length (bytes), Ticks/Op. *** *** 1,22.2894 *** *** 8,24.9805 *** *** 15,24.8632 *** *** 16,24.3448 *** *** 32,24.8554 *** *** 64,25.7541 *** ***128,29.1831 *** ***256,36.2345 *** ***512,45.8233 *** *** 1024, 103.4597 *** *** 2048, 163.5588 *** *** 4096, 232.7368 *** *** 8192, 368.1143 *** *** 16384, 649.0326 *** Test OK RTE>>quit Ravi Kerur (2): rte_memcmp functions using Intel AVX and SSE intrinsics Test cases for rte_memcmp functions app/test/Makefile | 31 +- app/test/autotest_data.py | 19 + app/test/test_memcmp.c | 250 +++ app/test/test_memcmp_perf.c| 396 +++ .../common/include/arch/arm/rte_memcmp.h | 60 ++ .../common/include/arch/ppc_64/rte_memcmp.h| 62 ++ .../common/include/arch/tile/rte_memcmp.h | 60 ++ .../common/include/arch/x86/rte_memcmp.h | 786 + lib/librte_eal/common/include/generic/rte_memcmp.h | 175 + 9 files changed, 1838 insertions(+), 1 deletion(-) create mode 100644 app/test/test_memcmp.c create mode 100644 app/test/test_memcmp_perf.c create mode 100644 lib/librte_eal/common/include/arch/arm/rte_memcmp.h create mode 100644 lib/librte_eal/common/include/arch/ppc_64/rte_memcmp.h create mode 100644 lib/librte_eal/common/include/arch/tile/rte_memcmp.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_memcmp.h create mode 100644 lib/librte_eal/common/include/generic/rte_memcmp.h -- 1.9.1
[dpdk-dev] [PATCH v2] I217 and I218 changes
Hi, Wenzhuo, Bruce, I have superseded old patch with a new submission. Please let me know if that approach is ok. Thanks, Ravi On Tue, Mar 1, 2016 at 5:21 PM, Lu, Wenzhuo wrote: > Hi Ravi, > > > > >Do you want me to resend it as 'v1' and include your comments in commit > message? let me know. > > I think it?s better if you withdraw this one, send a new one and make the > commit log easy to understand J And you can keep my ack. > > >
[dpdk-dev] [PATCH v1] I217 and I218 changes
v1: Make necessary changes to support I217 and I218 NICs.
Use v2' incorporating internal review comments as a base.
Internal review done by Wenzhuo Lu (Intel) and internal
review versions and testing shown below
v2':
Incorporate Wenzhuo's comments, remove superfluous
assignment to fc.requested_mode in em_hardware_init
function.
Compiled and tested (via testpmd) on Ubuntu 14.04 on target
x86_64-native-linuxapp-gcc
Compiled for target x86_64-native-linuxapp-clang
v1':
Modified driver and eal code to support I217 and I218
Intel NICs.
Compiled and tested (via testpmd) on Ubuntu 14.04 for target
x86_64-native-linuxapp-gcc
Compiled for target x86_64-native-linuxapp-clang
M. Jay(Intel) had used the patch for DPDK demo.
Signed-off-by: Ravi Kerur
Acked-by: Wenzhuo Lu
---
drivers/net/e1000/base/e1000_osdep.h| 26 +++-
drivers/net/e1000/em_ethdev.c | 32 +
lib/librte_eal/common/include/rte_pci_dev_ids.h | 9 +++
3 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e1000/base/e1000_osdep.h
b/drivers/net/e1000/base/e1000_osdep.h
index b2c76e3..47a1948 100644
--- a/drivers/net/e1000/base/e1000_osdep.h
+++ b/drivers/net/e1000/base/e1000_osdep.h
@@ -96,21 +96,35 @@ typedef int bool;
#define E1000_PCI_REG(reg) (*((volatile uint32_t *)(reg)))
+#define E1000_PCI_REG16(reg) (*((volatile uint16_t *)(reg)))
+
#define E1000_PCI_REG_WRITE(reg, value) do { \
E1000_PCI_REG((reg)) = (rte_cpu_to_le_32(value)); \
} while (0)
+#define E1000_PCI_REG_WRITE16(reg, value) do { \
+ E1000_PCI_REG16((reg)) = (rte_cpu_to_le_16(value)); \
+} while (0)
+
#define E1000_PCI_REG_ADDR(hw, reg) \
((volatile uint32_t *)((char *)(hw)->hw_addr + (reg)))
#define E1000_PCI_REG_ARRAY_ADDR(hw, reg, index) \
E1000_PCI_REG_ADDR((hw), (reg) + ((index) << 2))
-static inline uint32_t e1000_read_addr(volatile void* addr)
+#define E1000_PCI_REG_FLASH_ADDR(hw, reg) \
+ ((volatile uint32_t *)((char *)(hw)->flash_address + (reg)))
+
+static inline uint32_t e1000_read_addr(volatile void *addr)
{
return rte_le_to_cpu_32(E1000_PCI_REG(addr));
}
+static inline uint16_t e1000_read_addr16(volatile void *addr)
+{
+ return rte_le_to_cpu_16(E1000_PCI_REG16(addr));
+}
+
/* Necessary defines */
#define E1000_MRQC_ENABLE_MASK 0x0007
#define E1000_MRQC_RSS_FIELD_IPV6_EX 0x0008
@@ -155,20 +169,20 @@ static inline uint32_t e1000_read_addr(volatile void*
addr)
E1000_WRITE_REG(hw, reg, value)
/*
- * Not implemented.
+ * Tested on I217/I218 chipset.
*/
#define E1000_READ_FLASH_REG(hw, reg) \
- (E1000_ACCESS_PANIC(E1000_READ_FLASH_REG, hw, reg, 0), 0)
+ e1000_read_addr(E1000_PCI_REG_FLASH_ADDR((hw), (reg)))
#define E1000_READ_FLASH_REG16(hw, reg) \
- (E1000_ACCESS_PANIC(E1000_READ_FLASH_REG16, hw, reg, 0), 0)
+ e1000_read_addr16(E1000_PCI_REG_FLASH_ADDR((hw), (reg)))
#define E1000_WRITE_FLASH_REG(hw, reg, value) \
- E1000_ACCESS_PANIC(E1000_WRITE_FLASH_REG, hw, reg, value)
+ E1000_PCI_REG_WRITE(E1000_PCI_REG_FLASH_ADDR((hw), (reg)), (value))
#define E1000_WRITE_FLASH_REG16(hw, reg, value) \
- E1000_ACCESS_PANIC(E1000_WRITE_FLASH_REG16, hw, reg, value)
+ E1000_PCI_REG_WRITE16(E1000_PCI_REG_FLASH_ADDR((hw), (reg)), (value))
#define STATIC static
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 4a843fe..a8c26ed 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -231,6 +231,32 @@ rte_em_dev_atomic_write_link_status(struct rte_eth_dev
*dev,
return 0;
}
+/**
+ * eth_em_dev_is_ich8 - Check for ICH8 device
+ * @hw: pointer to the HW structure
+ *
+ * return TRUE for ICH8, otherwise FALSE
+ **/
+static bool
+eth_em_dev_is_ich8(struct e1000_hw *hw)
+{
+ DEBUGFUNC("eth_em_dev_is_ich8");
+
+ switch (hw->device_id) {
+ case E1000_DEV_ID_PCH_LPT_I217_LM:
+ case E1000_DEV_ID_PCH_LPT_I217_V:
+ case E1000_DEV_ID_PCH_LPTLP_I218_LM:
+ case E1000_DEV_ID_PCH_LPTLP_I218_V:
+ case E1000_DEV_ID_PCH_I218_V2:
+ case E1000_DEV_ID_PCH_I218_LM2:
+ case E1000_DEV_ID_PCH_I218_V3:
+ case E1000_DEV_ID_PCH_I218_LM3:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
static int
eth_em_dev_init(struct rte_eth_dev *eth_dev)
{
@@ -265,6 +291,8 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)
adapter->stopped = 0;
/* For ICH8 support we'll need to map the flash memory BAR */
+ if (eth_em_dev_is_ich8(hw))
+ hw->flash_addr
[dpdk-dev] [PATCH v1] I217 and I218 changes
v1: Make necessary changes to support I217 and I218 NICs.
Use v2' incorporating internal review comments as a base.
Internal review done by Wenzhou Lu (Intel) and internal
review versions and testing shown below
v2':
Incorporate Wenzhou's comments, remove superfluous
assignment to fc.requested_mode in em_hardware_init
function.
Compiled and tested (via testpmd) on Ubuntu 14.04 on target
x86_64-native-linuxapp-gcc
Compiled for target x86_64-native-linuxapp-clang
v1':
Modified driver and eal code to support I217 and I218
Intel NICs.
Compiled and tested (via testpmd) on Ubuntu 14.04 for target
x86_64-native-linuxapp-gcc
Compiled for target x86_64-native-linuxapp-clang
M. Jay(Intel) had used the patch for DPDK demo.
Signed-off-by: Ravi Kerur
Acked-by: Wenzhuo Lu
---
drivers/net/e1000/base/e1000_osdep.h| 26 +++-
drivers/net/e1000/em_ethdev.c | 32 +
lib/librte_eal/common/include/rte_pci_dev_ids.h | 9 +++
3 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e1000/base/e1000_osdep.h
b/drivers/net/e1000/base/e1000_osdep.h
index b2c76e3..47a1948 100644
--- a/drivers/net/e1000/base/e1000_osdep.h
+++ b/drivers/net/e1000/base/e1000_osdep.h
@@ -96,21 +96,35 @@ typedef int bool;
#define E1000_PCI_REG(reg) (*((volatile uint32_t *)(reg)))
+#define E1000_PCI_REG16(reg) (*((volatile uint16_t *)(reg)))
+
#define E1000_PCI_REG_WRITE(reg, value) do { \
E1000_PCI_REG((reg)) = (rte_cpu_to_le_32(value)); \
} while (0)
+#define E1000_PCI_REG_WRITE16(reg, value) do { \
+ E1000_PCI_REG16((reg)) = (rte_cpu_to_le_16(value)); \
+} while (0)
+
#define E1000_PCI_REG_ADDR(hw, reg) \
((volatile uint32_t *)((char *)(hw)->hw_addr + (reg)))
#define E1000_PCI_REG_ARRAY_ADDR(hw, reg, index) \
E1000_PCI_REG_ADDR((hw), (reg) + ((index) << 2))
-static inline uint32_t e1000_read_addr(volatile void* addr)
+#define E1000_PCI_REG_FLASH_ADDR(hw, reg) \
+ ((volatile uint32_t *)((char *)(hw)->flash_address + (reg)))
+
+static inline uint32_t e1000_read_addr(volatile void *addr)
{
return rte_le_to_cpu_32(E1000_PCI_REG(addr));
}
+static inline uint16_t e1000_read_addr16(volatile void *addr)
+{
+ return rte_le_to_cpu_16(E1000_PCI_REG16(addr));
+}
+
/* Necessary defines */
#define E1000_MRQC_ENABLE_MASK 0x0007
#define E1000_MRQC_RSS_FIELD_IPV6_EX 0x0008
@@ -155,20 +169,20 @@ static inline uint32_t e1000_read_addr(volatile void*
addr)
E1000_WRITE_REG(hw, reg, value)
/*
- * Not implemented.
+ * Tested on I217/I218 chipset.
*/
#define E1000_READ_FLASH_REG(hw, reg) \
- (E1000_ACCESS_PANIC(E1000_READ_FLASH_REG, hw, reg, 0), 0)
+ e1000_read_addr(E1000_PCI_REG_FLASH_ADDR((hw), (reg)))
#define E1000_READ_FLASH_REG16(hw, reg) \
- (E1000_ACCESS_PANIC(E1000_READ_FLASH_REG16, hw, reg, 0), 0)
+ e1000_read_addr16(E1000_PCI_REG_FLASH_ADDR((hw), (reg)))
#define E1000_WRITE_FLASH_REG(hw, reg, value) \
- E1000_ACCESS_PANIC(E1000_WRITE_FLASH_REG, hw, reg, value)
+ E1000_PCI_REG_WRITE(E1000_PCI_REG_FLASH_ADDR((hw), (reg)), (value))
#define E1000_WRITE_FLASH_REG16(hw, reg, value) \
- E1000_ACCESS_PANIC(E1000_WRITE_FLASH_REG16, hw, reg, value)
+ E1000_PCI_REG_WRITE16(E1000_PCI_REG_FLASH_ADDR((hw), (reg)), (value))
#define STATIC static
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 4a843fe..a8c26ed 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -231,6 +231,32 @@ rte_em_dev_atomic_write_link_status(struct rte_eth_dev
*dev,
return 0;
}
+/**
+ * eth_em_dev_is_ich8 - Check for ICH8 device
+ * @hw: pointer to the HW structure
+ *
+ * return TRUE for ICH8, otherwise FALSE
+ **/
+static bool
+eth_em_dev_is_ich8(struct e1000_hw *hw)
+{
+ DEBUGFUNC("eth_em_dev_is_ich8");
+
+ switch (hw->device_id) {
+ case E1000_DEV_ID_PCH_LPT_I217_LM:
+ case E1000_DEV_ID_PCH_LPT_I217_V:
+ case E1000_DEV_ID_PCH_LPTLP_I218_LM:
+ case E1000_DEV_ID_PCH_LPTLP_I218_V:
+ case E1000_DEV_ID_PCH_I218_V2:
+ case E1000_DEV_ID_PCH_I218_LM2:
+ case E1000_DEV_ID_PCH_I218_V3:
+ case E1000_DEV_ID_PCH_I218_LM3:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
static int
eth_em_dev_init(struct rte_eth_dev *eth_dev)
{
@@ -265,6 +291,8 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)
adapter->stopped = 0;
/* For ICH8 support we'll need to map the flash memory BAR */
+ if (eth_em_dev_is_ich8(hw))
+ hw->flash_addr
[dpdk-dev] [PATCH v2] I217 and I218 changes
On Mon, Feb 29, 2016 at 9:18 PM, Lu, Wenzhuo wrote: > Hi, > > > -Original Message- > > From: Ravi Kerur [mailto:rkerur at gmail.com] > > Sent: Tuesday, March 1, 2016 2:31 AM > > To: Lu, Wenzhuo; dev at dpdk.org > > Cc: Ravi Kerur > > Subject: [PATCH v2] I217 and I218 changes > > > > v2: > > Incorporate Wenzhou's comments > > Compiled and tested (via testpmd) on Ubuntu 14.04 on target > > x86_64-native-linuxapp-gcc > > Compiled for target x86_64-native-linuxapp-clang > > > > v1: > > Modified driver and eal code to recognize and support I217 and > > I218 Intel NICs. > > Compiled and tested (via testpmd) on Ubuntu 14.04 for target > > x86_64-native-linuxapp-gcc > > Compiled for target x86_64-native-linuxapp-clang > > > > Signed-off-by: Ravi Kerur > Acked-by: Wenzhuo Lu > But the v1, v2 info in the commit log is a little strange. For you didn't > send a v1 and others don't know our discussion :) > > Do you want me to resend it as 'v1' and include your comments in commit message? let me know. Thanks.
[dpdk-dev] [PATCH v2] I217 and I218 changes
v2:
Incorporate Wenzhou's comments
Compiled and tested (via testpmd) on Ubuntu 14.04 on target
x86_64-native-linuxapp-gcc
Compiled for target x86_64-native-linuxapp-clang
v1:
Modified driver and eal code to recognize and support I217 and
I218 Intel NICs.
Compiled and tested (via testpmd) on Ubuntu 14.04 for target
x86_64-native-linuxapp-gcc
Compiled for target x86_64-native-linuxapp-clang
Signed-off-by: Ravi Kerur
---
drivers/net/e1000/base/e1000_osdep.h| 26 +++-
drivers/net/e1000/em_ethdev.c | 32 +
lib/librte_eal/common/include/rte_pci_dev_ids.h | 9 +++
3 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e1000/base/e1000_osdep.h
b/drivers/net/e1000/base/e1000_osdep.h
index b2c76e3..47a1948 100644
--- a/drivers/net/e1000/base/e1000_osdep.h
+++ b/drivers/net/e1000/base/e1000_osdep.h
@@ -96,21 +96,35 @@ typedef int bool;
#define E1000_PCI_REG(reg) (*((volatile uint32_t *)(reg)))
+#define E1000_PCI_REG16(reg) (*((volatile uint16_t *)(reg)))
+
#define E1000_PCI_REG_WRITE(reg, value) do { \
E1000_PCI_REG((reg)) = (rte_cpu_to_le_32(value)); \
} while (0)
+#define E1000_PCI_REG_WRITE16(reg, value) do { \
+ E1000_PCI_REG16((reg)) = (rte_cpu_to_le_16(value)); \
+} while (0)
+
#define E1000_PCI_REG_ADDR(hw, reg) \
((volatile uint32_t *)((char *)(hw)->hw_addr + (reg)))
#define E1000_PCI_REG_ARRAY_ADDR(hw, reg, index) \
E1000_PCI_REG_ADDR((hw), (reg) + ((index) << 2))
-static inline uint32_t e1000_read_addr(volatile void* addr)
+#define E1000_PCI_REG_FLASH_ADDR(hw, reg) \
+ ((volatile uint32_t *)((char *)(hw)->flash_address + (reg)))
+
+static inline uint32_t e1000_read_addr(volatile void *addr)
{
return rte_le_to_cpu_32(E1000_PCI_REG(addr));
}
+static inline uint16_t e1000_read_addr16(volatile void *addr)
+{
+ return rte_le_to_cpu_16(E1000_PCI_REG16(addr));
+}
+
/* Necessary defines */
#define E1000_MRQC_ENABLE_MASK 0x0007
#define E1000_MRQC_RSS_FIELD_IPV6_EX 0x0008
@@ -155,20 +169,20 @@ static inline uint32_t e1000_read_addr(volatile void*
addr)
E1000_WRITE_REG(hw, reg, value)
/*
- * Not implemented.
+ * Tested on I217/I218 chipset.
*/
#define E1000_READ_FLASH_REG(hw, reg) \
- (E1000_ACCESS_PANIC(E1000_READ_FLASH_REG, hw, reg, 0), 0)
+ e1000_read_addr(E1000_PCI_REG_FLASH_ADDR((hw), (reg)))
#define E1000_READ_FLASH_REG16(hw, reg) \
- (E1000_ACCESS_PANIC(E1000_READ_FLASH_REG16, hw, reg, 0), 0)
+ e1000_read_addr16(E1000_PCI_REG_FLASH_ADDR((hw), (reg)))
#define E1000_WRITE_FLASH_REG(hw, reg, value) \
- E1000_ACCESS_PANIC(E1000_WRITE_FLASH_REG, hw, reg, value)
+ E1000_PCI_REG_WRITE(E1000_PCI_REG_FLASH_ADDR((hw), (reg)), (value))
#define E1000_WRITE_FLASH_REG16(hw, reg, value) \
- E1000_ACCESS_PANIC(E1000_WRITE_FLASH_REG16, hw, reg, value)
+ E1000_PCI_REG_WRITE16(E1000_PCI_REG_FLASH_ADDR((hw), (reg)), (value))
#define STATIC static
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 4a843fe..a8c26ed 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -231,6 +231,32 @@ rte_em_dev_atomic_write_link_status(struct rte_eth_dev
*dev,
return 0;
}
+/**
+ * eth_em_dev_is_ich8 - Check for ICH8 device
+ * @hw: pointer to the HW structure
+ *
+ * return TRUE for ICH8, otherwise FALSE
+ **/
+static bool
+eth_em_dev_is_ich8(struct e1000_hw *hw)
+{
+ DEBUGFUNC("eth_em_dev_is_ich8");
+
+ switch (hw->device_id) {
+ case E1000_DEV_ID_PCH_LPT_I217_LM:
+ case E1000_DEV_ID_PCH_LPT_I217_V:
+ case E1000_DEV_ID_PCH_LPTLP_I218_LM:
+ case E1000_DEV_ID_PCH_LPTLP_I218_V:
+ case E1000_DEV_ID_PCH_I218_V2:
+ case E1000_DEV_ID_PCH_I218_LM2:
+ case E1000_DEV_ID_PCH_I218_V3:
+ case E1000_DEV_ID_PCH_I218_LM3:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
static int
eth_em_dev_init(struct rte_eth_dev *eth_dev)
{
@@ -265,6 +291,8 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)
adapter->stopped = 0;
/* For ICH8 support we'll need to map the flash memory BAR */
+ if (eth_em_dev_is_ich8(hw))
+ hw->flash_address = (void *)pci_dev->mem_resource[1].addr;
if (e1000_setup_init_funcs(hw, TRUE) != E1000_SUCCESS ||
em_hw_init(hw) != 0) {
@@ -490,6 +518,7 @@ em_set_pba(struct e1000_hw *hw)
break;
case e1000_pchlan:
case e1000_pch2lan:
+ case e1000_pch_lpt:
pba = E1000_PBA_26K;
break;
default:
@@ -798,6 +827,8 @@ em_hardware_init(struct e1000_hw *hw)
hw->fc.low_wa
[dpdk-dev] [dpdk-dev,v2] Clean up rte_memcpy.h file
On Wed, Jan 27, 2016 at 8:18 PM, Zhihong Wang
wrote:
> > Remove unnecessary type casting in functions.
> >
> > Tested on Ubuntu (14.04 x86_64) with "make test".
> > "make test" results match the results with baseline.
> > "Memcpy perf" results match the results with baseline.
> >
> > Signed-off-by: Ravi Kerur
> > Acked-by: Stephen Hemminger
> >
> > ---
> > .../common/include/arch/x86/rte_memcpy.h | 340
> +++--
> > 1 file changed, 175 insertions(+), 165 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> > index 6a57426..839d4ec 100644
> > --- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> > +++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
>
> [...]
>
> > /**
> > @@ -150,13 +150,16 @@ rte_mov64blocks(uint8_t *dst, const uint8_t *src,
> size_t n)
> > __m256i ymm0, ymm1;
> >
> > while (n >= 64) {
> > - ymm0 = _mm256_loadu_si256((const __m256i *)((const uint8_t
> *)src + 0 * 32));
> > +
> > + ymm0 = _mm256_loadu_si256((const __m256i *)(src + 0 * 32));
> > + ymm1 = _mm256_loadu_si256((const __m256i *)(src + 1 * 32));
> > +
> > + _mm256_storeu_si256((__m256i *)(dst + 0 * 32), ymm0);
> > + _mm256_storeu_si256((__m256i *)(dst + 1 * 32), ymm1);
> > +
>
> Any particular reason to change the order of the statements here? :)
> Overall this patch looks good.
>
I checked the code changes, initial code had moving addresses (src and
dst) and decrement counter scattered between store and load instructions. I
changed it to loads, followed by stores and handle address/counters
increment/decrement without changing functionality.
>
> > n -= 64;
> > - ymm1 = _mm256_loadu_si256((const __m256i *)((const uint8_t
> *)src + 1 * 32));
> > - src = (const uint8_t *)src + 64;
> > - _mm256_storeu_si256((__m256i *)((uint8_t *)dst + 0 * 32),
> ymm0);
> > - _mm256_storeu_si256((__m256i *)((uint8_t *)dst + 1 * 32),
> ymm1);
> > - dst = (uint8_t *)dst + 64;
> > + src = src + 64;
> > + dst = dst + 64;
> > }
> > }
> >
>
>
[dpdk-dev] [dpdk-dev, v3] Implement memcmp using Intel SIMD instrinsics.
On Tue, Feb 23, 2016 at 4:22 AM, Wang, Zhihong wrote: > > > It'd be great if you could format this patch into a patch set with > several > > > little ones. :-) > > > Also, the kernel checkpatch is very helpful. > > > Good coding style and patch organization make it easy for in-depth > reviews. > > > > > Combination of scalar and vector (32/64/128) was done to get optimal > performance numbers. If there is enough interest in this I can work on it > and provide an updated patch set. > > That'll be very helpful! Looking forward to your patch :) > BTW, have you tested real example performance with your patch? > Yes it was tested with hash functions in dpdk code.I will work on it and send updated patch. Thanks for your inputs I will incorporate them in next patch series.
[dpdk-dev] [dpdk-dev, v3] Implement memcmp using Intel SIMD instrinsics.
On Wed, Jan 27, 2016 at 7:08 PM, Zhihong Wang
wrote:
> > diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcmp.h b/lib
> > /librte_eal/common/include/arch/x86/rte_memcmp.h
>
> [...]
>
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +/**
> > + * Compare bytes between two locations. The locations must not overlap.
> > + *
>
> Parameter names should be kept consistent as they are in function body.
>
> > + * @param src_1
> > + * Pointer to the first source of the data.
> > + * @param src_2
> > + * Pointer to the second source of the data.
> > + * @param n
> > + * Number of bytes to compare.
> > + * @return
> > + * zero if src_1 equal src_2
> > + * -ve if src_1 less than src_2
> > + * +ve if src_1 greater than src_2
> > + */
> > +static inline int
> > +rte_memcmp(const void *src_1, const void *src,
> > + size_t n) __attribute__((always_inline));
> > +
> > +/**
> > + * Find the first different bit for comparison.
> > + */
> > +static inline int
> > +rte_cmpffd (uint32_t x, uint32_t y)
> > +{
> > + int i;
> > + int pos = x ^ y;
> > + for (i = 0; i < 32; i++)
> > + if (pos & (1<
> Coding style check :-)
> BTW, does the bsf instruction provide this check?
>
> > + return i;
> > + return -1;
> > +}
> > +
>
> [...]
>
> > +/**
> > + * Compare 48 bytes between two locations.
> > + * Locations should not overlap.
> > + */
> > +static inline int
> > +rte_cmp48(const void *src_1, const void *src_2)
>
> Guess this is not used.
>
I had left _unused_ with the assumption that it might be needed when actual
performance tests are done on high end servers.
>
> [...]
>
> > +/**
> > + * Compare 256 bytes between two locations.
> > + * Locations should not overlap.
> > + */
> > +static inline int
> > +rte_cmp256(const void *src_1, const void *src_2)
> > +{
> > + int ret;
> > +
> > + ret = rte_cmp64((const uint8_t *)src_1 + 0 * 64,
> > + (const uint8_t *)src_2 + 0 * 64);
>
> Why not just use rte_cmp128?
>
>
> [...]
>
> > +static inline int
> > +rte_memcmp(const void *_src_1, const void *_src_2, size_t n)
> > +{
> > + const uint8_t *src_1 = (const uint8_t *)_src_1;
> > + const uint8_t *src_2 = (const uint8_t *)_src_2;
> > + int ret = 0;
> > +
> > + if (n < 16)
> > + return rte_memcmp_regular(src_1, src_2, n);
> > +
> > + if (n <= 32) {
> > + ret = rte_cmp16(src_1, src_2);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + return rte_cmp16(src_1 - 16 + n, src_2 - 16 + n);
> > + }
> > +
>
> Too many conditions here may harm the overall performance.
> It's a trade-off thing, all about balancing the overhead.
> Just make sure this is tuned based on actual test numbers.
>
>
> > + if (n <= 48) {
> > + ret = rte_cmp32(src_1, src_2);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + return rte_cmp16(src_1 - 16 + n, src_2 - 16 + n);
> > + }
> > +
> > + if (n <= 64) {
> > + ret = rte_cmp32(src_1, src_2);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + ret = rte_cmp16(src_1 + 32, src_2 + 32);
> > +
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + return rte_cmp16(src_1 - 16 + n, src_2 - 16 + n);
> > + }
> > +
> > + if (n <= 96) {
> > + ret = rte_cmp64(src_1, src_2);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + ret = rte_cmp16(src_1 + 64, src_2 + 64);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + return rte_cmp16(src_1 - 16 + n, src_2 - 16 + n);
> > + }
> > +
> > + if (n <= 128) {
> > + ret = rte_cmp64(src_1, src_2);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + ret = rte_cmp32(src_1 + 64, src_2 + 64);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + ret = rte_cmp16(src_1 + 96, src_2 + 96);
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + return rte_cmp16(src_1 - 16 + n, src_2 - 16 + n);
> > + }
>
> [...]
>
> > +/**
> > + * Compare 48 bytes between two locations.
> > + * Locations should not overlap.
> > + */
> > +static inline int
> > +rte_cmp48(const void *src_1, const void *src_2)
>
> Not used.
>
> > +{
> > + int ret;
> > +
> > + ret = rte_cmp16((const uint8_t *)src_1 + 0 * 16,
> > + (const uint8_t *)src_2 + 0 * 16);
> > +
> > + if (unlikely(ret != 0))
> > + return ret;
> > +
> > + ret = rte_cmp16((const uint8_t *)src_1 + 1 * 16,
> > + (const uint8_t *)src_2 + 1 * 16);
> > +
> > + if (unlikely(ret != 0))
> > + retur
[dpdk-dev] [dpdk-dev,v2] Clean up rte_memcpy.h file
On Wed, Jan 27, 2016 at 8:18 PM, Zhihong Wang
wrote:
> > Remove unnecessary type casting in functions.
> >
> > Tested on Ubuntu (14.04 x86_64) with "make test".
> > "make test" results match the results with baseline.
> > "Memcpy perf" results match the results with baseline.
> >
> > Signed-off-by: Ravi Kerur
> > Acked-by: Stephen Hemminger
> >
> > ---
> > .../common/include/arch/x86/rte_memcpy.h | 340
> +++--
> > 1 file changed, 175 insertions(+), 165 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> > index 6a57426..839d4ec 100644
> > --- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> > +++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
>
> [...]
>
> > /**
> > @@ -150,13 +150,16 @@ rte_mov64blocks(uint8_t *dst, const uint8_t *src,
> size_t n)
> > __m256i ymm0, ymm1;
> >
> > while (n >= 64) {
> > - ymm0 = _mm256_loadu_si256((const __m256i *)((const uint8_t
> *)src + 0 * 32));
> > +
> > + ymm0 = _mm256_loadu_si256((const __m256i *)(src + 0 * 32));
> > + ymm1 = _mm256_loadu_si256((const __m256i *)(src + 1 * 32));
> > +
> > + _mm256_storeu_si256((__m256i *)(dst + 0 * 32), ymm0);
> > + _mm256_storeu_si256((__m256i *)(dst + 1 * 32), ymm1);
> > +
>
> Any particular reason to change the order of the statements here? :)
> Overall this patch looks good.
>
Sorry for the late response. Let me double check and get back to you, it's
been a while since I did the changes.
> > n -= 64;
> > - ymm1 = _mm256_loadu_si256((const __m256i *)((const uint8_t
> *)src + 1 * 32));
> > - src = (const uint8_t *)src + 64;
> > - _mm256_storeu_si256((__m256i *)((uint8_t *)dst + 0 * 32),
> ymm0);
> > - _mm256_storeu_si256((__m256i *)((uint8_t *)dst + 1 * 32),
> ymm1);
> > - dst = (uint8_t *)dst + 64;
> > + src = src + 64;
> > + dst = dst + 64;
> > }
> > }
> >
>
>
[dpdk-dev] [PATCH v1] Modify and modularize l3fwd code
v1: > Rebase to latest code base for DPDK team review. Intel team's (Konstantin, Bruce and Declan) review comments v4<-v3: > Fix code review comments from Konstantin > Move buffer optimization code into l3fwd_lpm_sse.h and l3fwd_em_sse.h for LPM and EM respectively > Add compile time __SSE4_1__ for header file inclusion > Tested with CONFIG_RTE_MACHINE=default for non __SSE4_1__ compilation and build > Compiled for GCC 4.8.4 and 5.1 on Ubuntu 14.04 v3<-v2: > Fix code review comments from Bruce > Fix multiple static definitions > Move local #defines to C files, common #defines to H file. > Rename ipv4_l3fwd_route to ipv4_l3fwd_lpm and ipv4_l3fwd_em > Rename ipv6_l3fwd_route to ipv6_l3fwd_lpm and ipv6_l3fwd_lpm > Pass additional parameter to send_single_packet > Compiled for GCC 4.8.4 and 5.1 on Ubuntu 14.04 v2<-v1: > Fix errors in GCC 5.1 > Restore "static inline" functions, rearrange functions to take "static inline" into account > Duplicate main_loop for LPM and EM v1: > Split main.c into following 3 files > main.c, (parsing, buffer alloc, and other utilities) > l3fwd_lpm.c, (Longest Prefix Match functions) > l3fwd_em.c, (Exact Match f.e. Hash functions) > l3fwd.h, (Common defines and prototypes) > Select LPM or EM based on run time selection f.e. > l3fwd -c 0x1 -n 1 -- -p 0x1 -E ... (Exact Match) > l3fwd -c 0x1 -n 1 -- -p 0x1 -L ... (LPM) > Options "E" and "L" are mutualy-exclusive. > Use function pointers during initialiation of relevant data structures. > Remove unwanted #ifdefs in the code with exception to > DO_RFC_1812_CHECKS > RTE_MACHINE_CPUFLAG_SSE4_2 > Compiled for > i686-native-linuxapp-gcc > x86_64-native-linuxapp-gcc > x86_x32-native-linuxapp-gcc > x86_64-native-bsdapp-gcc > Tested on > Ubuntu 14.04 (GCC 4.8.4) > FreeBSD 10.0 (GCC 4.8) > I217 and I218 respectively. Signed-off-by: Ravi Kerur --- examples/l3fwd/Makefile|9 +- examples/l3fwd/l3fwd.h | 209 examples/l3fwd/l3fwd_em.c | 773 ++ examples/l3fwd/l3fwd_em_sse.h | 479 + examples/l3fwd/l3fwd_lpm.c | 414 examples/l3fwd/l3fwd_lpm_sse.h | 610 +++ examples/l3fwd/main.c | 2202 7 files changed, 2694 insertions(+), 2002 deletions(-) create mode 100644 examples/l3fwd/l3fwd.h create mode 100644 examples/l3fwd/l3fwd_em.c create mode 100644 examples/l3fwd/l3fwd_em_sse.h create mode 100644 examples/l3fwd/l3fwd_lpm.c create mode 100644 examples/l3fwd/l3fwd_lpm_sse.h diff --git a/examples/l3fwd/Makefile b/examples/l3fwd/Makefile index 68de8fc..94a2282 100644 --- a/examples/l3fwd/Makefile +++ b/examples/l3fwd/Makefile @@ -42,15 +42,10 @@ include $(RTE_SDK)/mk/rte.vars.mk APP = l3fwd # all source are stored in SRCS-y -SRCS-y := main.c +SRCS-y := main.c l3fwd_lpm.c l3fwd_em.c +CFLAGS += -I$(SRCDIR) CFLAGS += -O3 $(USER_FLAGS) CFLAGS += $(WERROR_FLAGS) -# workaround for a gcc bug with noreturn attribute -# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 -ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) -CFLAGS_main.o += -Wno-return-type -endif - include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h new file mode 100644 index 000..50e40fe --- /dev/null +++ b/examples/l3fwd/l3fwd.h @@ -0,0 +1,209 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2010-2015 Intel Corporation. All rights reserved. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of Intel Corporation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WAR
[dpdk-dev] [PATCH v1] Modify and modularize l3fwd code
Many thanks to Intel team (Konstantin, Bruce and Declan) for below proposal to
make changes to l3fwd code, their valuable inputs during interal review and help
in performance tests.
The main problem with l3fwd is that it is too monolithic with everything being
in one file, and the various options all controlled by compile time flags. This
means that it's hard to read and understand, and when making any changes, you
need
to go to a lot of work to try and ensure you cover all the code paths, since a
compile of the app will not touch large parts of the l3fwd codebase.
Following changes were done to fix the issues mentioned above
> Split out the various lpm and hash specific functionality into
separate
files, so that l3fwd code has one file for common code e.g. args
processing, mempool creation, and then individual files for the
various
forwarding approaches.
Following are new file lists
main.c (Common code for args processing, memppol creation, etc)
l3fwd_em.c (Hash/Exact match aka 'EM' functionality)
l3fwd_em_sse.h (SSE4_1 buffer optimizated 'EM' code)
l3fwd_lpm.c (Longest Prefix Match aka 'LPM' functionality)
l3fwd_lpm_sse.h (SSE4_1 buffer optimizated 'LPM' code)
l3fwd.h (Common include for 'EM' and 'LPM')
> The choosing of the lpm/hash path should be done at runtime, not
compile time, via a command-line argument. This will ensure that
both code paths get compiled in a single go
Following examples show runtime options provided
Select 'LPM' or 'EM' based on run time selection f.e.
> l3fwd -c 0x1 -n 1 -- -p 0x1 -E ... (EM)
> l3fwd -c 0x1 -n 1 -- -p 0x1 -L ... (LPM)
Options "E" and "L" are mutualy-exclusive.
If none selected, "L" is default.
Ravi Kerur (1):
Modify and modularize l3fwd code
examples/l3fwd/Makefile|9 +-
examples/l3fwd/l3fwd.h | 209
examples/l3fwd/l3fwd_em.c | 773 ++
examples/l3fwd/l3fwd_em_sse.h | 479 +
examples/l3fwd/l3fwd_lpm.c | 414
examples/l3fwd/l3fwd_lpm_sse.h | 610 +++
examples/l3fwd/main.c | 2202
7 files changed, 2694 insertions(+), 2002 deletions(-)
create mode 100644 examples/l3fwd/l3fwd.h
create mode 100644 examples/l3fwd/l3fwd_em.c
create mode 100644 examples/l3fwd/l3fwd_em_sse.h
create mode 100644 examples/l3fwd/l3fwd_lpm.c
create mode 100644 examples/l3fwd/l3fwd_lpm_sse.h
--
1.9.1
[dpdk-dev] [PATCH v4] Move rte_mbuf macros to common header file
Macros RTE_MBUF_DATA_DMA_ADDR and RTE_MBUF_DATA_DMA_ADDR_DEFAULT
are defined in each PMD driver file. Convert macros to inline
functions and move them to common lib/librte_mbuf/rte_mbuf.h file.
PMD drivers include rte_mbuf.h file directly/indirectly hence no
additionl header file inclusion is necessary.
v4:
> Remove un-necessary cast and braces in inline functions.
> Add 'const' for function parameters
v3:
> Changed converted macro->inline names to lower-case
> Fix checkpatch.pl errors and warnings
(camelcase warning is not fixed)
> Compiled following targets
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> x86_64-native-bsdapp-gcc
> x86_64-native-bsdapp-clang
> Tested on:
> x86_64 ubuntu 14.04, make test
v2:
> Changed both macros to inline functions in all PMD
> Changed macro to rte_pktmbuf_mtod in xenvirt module
> Compiled following targets:
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> Tested on:
> x86_64 ubuntu 14.04, testpmd and make test
v1:
> Move macros into common rte_mbuf header file.
> Compiled following targets:
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> x86_64-native-bsdapp-gcc
> x86_64-native-bsdapp-clang
Tested on:
> x86_64 Ubuntu 14.04, testpmd and make test
> FreeBSD 10.1, testpmd
Signed-off-by: Ravi Kerur
---
drivers/net/bnx2x/bnx2x.c | 2 +-
drivers/net/bnx2x/bnx2x.h | 3 ---
drivers/net/cxgbe/sge.c| 3 ---
drivers/net/e1000/em_rxtx.c| 15 +--
drivers/net/e1000/igb_rxtx.c | 14 --
drivers/net/i40e/i40e_rxtx.c | 20 +++-
drivers/net/ixgbe/ixgbe_rxtx.c | 14 +++---
drivers/net/ixgbe/ixgbe_rxtx.h | 6 --
drivers/net/virtio/virtio_rxtx.c | 2 +-
drivers/net/virtio/virtqueue.h | 3 ---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 11 +++
drivers/net/xenvirt/virtqueue.h| 5 +
lib/librte_mbuf/rte_mbuf.h | 12
13 files changed, 41 insertions(+), 69 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index fed7a06..a3f118c 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2147,7 +2147,7 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct
rte_mbuf **m_head, int m_p
tx_start_bd = &txq->tx_ring[TX_BD(bd_prod, txq)].start_bd;
tx_start_bd->addr =
- rte_cpu_to_le_64(RTE_MBUF_DATA_DMA_ADDR(m0));
+ rte_cpu_to_le_64(rte_mbuf_data_dma_addr(m0));
tx_start_bd->nbytes = rte_cpu_to_le_16(m0->data_len);
tx_start_bd->bd_flags.as_bitfield = ETH_TX_BD_FLAGS_START_BD;
tx_start_bd->general_data =
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 867b92a..28bd83f 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -141,9 +141,6 @@ struct bnx2x_device_type {
char *bnx2x_name;
};
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- ((uint64_t)((mb)->buf_physaddr + (mb)->data_off))
-
#define BNX2X_PAGE_SHIFT 12
#define BNX2X_PAGE_SIZE(1 << BNX2X_PAGE_SHIFT)
#define BNX2X_PAGE_MASK(~(BNX2X_PAGE_SIZE - 1))
diff --git a/drivers/net/cxgbe/sge.c b/drivers/net/cxgbe/sge.c
index 6eb1244..8f4c025 100644
--- a/drivers/net/cxgbe/sge.c
+++ b/drivers/net/cxgbe/sge.c
@@ -1267,9 +1267,6 @@ static struct rte_mbuf *t4_pktgl_to_mbuf(const struct
pkt_gl *gl)
return t4_pktgl_to_mbuf_usembufs(gl);
}
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- ((dma_addr_t) ((mb)->buf_physaddr + (mb)->data_off))
-
/**
* t4_ethrx_handler - process an ingress ethernet packet
* @q: the response queue that received the packet
diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
index 3b8776d..39c9744 100644
--- a/drivers/net/e1000/em_rxtx.c
+++ b/drivers/net/e1000/em_rxtx.c
@@ -88,12 +88,6 @@ rte_rxmbuf_alloc(struct rte_mempool *mp)
return (m);
}
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
/**
* Structure associated with each descriptor of the RX ring of a RX queue.
*/
@@ -585,7 +579,7 @@ eth_em_xmit_pkts(void *tx_queue, struct rte_m
[dpdk-dev] [PATCH v4] Move rte_mbuf macros to common header file
Macros RTE_MBUF_DATA_DMA_ADDR and RTE_MBUF_DATA_DMA_ADDR_DEFAULT
are defined in each PMD driver file. Convert macros to inline
functions and move them to common lib/librte_mbuf/rte_mbuf.h file.
PMD drivers include rte_mbuf.h file directly/indirectly hence no
additionl header file inclusion is necessary.
v4:
> Remove un-necessary cast and braces in inline functions.
v3:
> Changed converted macro->inline names to lower-case
> Fix checkpatch.pl errors and warnings
(camelcase warning is not fixed)
> Compiled following targets
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> x86_64-native-bsdapp-gcc
> x86_64-native-bsdapp-clang
> Tested on:
> x86_64 ubuntu 14.04, make test
v2:
> Changed both macros to inline functions in all PMD
> Changed macro to rte_pktmbuf_mtod in xenvirt module
> Compiled following targets:
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> Tested on:
> x86_64 ubuntu 14.04, testpmd and make test
v1:
> Move macros into common rte_mbuf header file.
> Compiled following targets:
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> x86_64-native-bsdapp-gcc
> x86_64-native-bsdapp-clang
Tested on:
> x86_64 Ubuntu 14.04, testpmd and 'make test'
> FreeBSD 10.1, testpmd
Signed-off-by: Ravi Kerur
---
drivers/net/bnx2x/bnx2x.c | 2 +-
drivers/net/bnx2x/bnx2x.h | 3 ---
drivers/net/cxgbe/sge.c| 3 ---
drivers/net/e1000/em_rxtx.c| 15 +--
drivers/net/e1000/igb_rxtx.c | 14 --
drivers/net/i40e/i40e_rxtx.c | 20 +++-
drivers/net/ixgbe/ixgbe_rxtx.c | 14 +++---
drivers/net/ixgbe/ixgbe_rxtx.h | 6 --
drivers/net/virtio/virtio_rxtx.c | 2 +-
drivers/net/virtio/virtqueue.h | 3 ---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 11 +++
drivers/net/xenvirt/virtqueue.h| 5 +
lib/librte_mbuf/rte_mbuf.h | 13 +
13 files changed, 42 insertions(+), 69 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index fed7a06..a3f118c 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2147,7 +2147,7 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct
rte_mbuf **m_head, int m_p
tx_start_bd = &txq->tx_ring[TX_BD(bd_prod, txq)].start_bd;
tx_start_bd->addr =
- rte_cpu_to_le_64(RTE_MBUF_DATA_DMA_ADDR(m0));
+ rte_cpu_to_le_64(rte_mbuf_data_dma_addr(m0));
tx_start_bd->nbytes = rte_cpu_to_le_16(m0->data_len);
tx_start_bd->bd_flags.as_bitfield = ETH_TX_BD_FLAGS_START_BD;
tx_start_bd->general_data =
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 867b92a..28bd83f 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -141,9 +141,6 @@ struct bnx2x_device_type {
char *bnx2x_name;
};
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- ((uint64_t)((mb)->buf_physaddr + (mb)->data_off))
-
#define BNX2X_PAGE_SHIFT 12
#define BNX2X_PAGE_SIZE(1 << BNX2X_PAGE_SHIFT)
#define BNX2X_PAGE_MASK(~(BNX2X_PAGE_SIZE - 1))
diff --git a/drivers/net/cxgbe/sge.c b/drivers/net/cxgbe/sge.c
index 6eb1244..8f4c025 100644
--- a/drivers/net/cxgbe/sge.c
+++ b/drivers/net/cxgbe/sge.c
@@ -1267,9 +1267,6 @@ static struct rte_mbuf *t4_pktgl_to_mbuf(const struct
pkt_gl *gl)
return t4_pktgl_to_mbuf_usembufs(gl);
}
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- ((dma_addr_t) ((mb)->buf_physaddr + (mb)->data_off))
-
/**
* t4_ethrx_handler - process an ingress ethernet packet
* @q: the response queue that received the packet
diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
index 3b8776d..39c9744 100644
--- a/drivers/net/e1000/em_rxtx.c
+++ b/drivers/net/e1000/em_rxtx.c
@@ -88,12 +88,6 @@ rte_rxmbuf_alloc(struct rte_mempool *mp)
return (m);
}
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
/**
* Structure associated with each descriptor of the RX ring of a RX queue.
*/
@@ -585,7 +579,7 @@ eth_em_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
* Set up Transmit Data Des
[dpdk-dev] [PATCH v2] Move rte_mbuf macros to common header file
On Wed, Sep 30, 2015 at 12:41 PM, Aaron Conole wrote:
> Ravi Kerur writes:
>
> > Macros RTE_MBUF_DATA_DMA_ADDR and RTE_MBUF_DATA_DMA_ADDR_DEFAULT
> > are defined in each PMD driver file. Move those macros into common
> > lib/librte_mbuf/rte_mbuf.h file. PMD drivers include rte_mbuf.h
> > file directly/indirectly hence no additionl header file inclusion
> > is necessary.
> I think this should also mention that they are no longer macros, as
> well.
>
> <>
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -843,6 +843,16 @@ struct rte_mbuf {
> > uint16_t timesync;
> > } __rte_cache_aligned;
> >
> > +static inline uint64_t RTE_MBUF_DATA_DMA_ADDR(struct rte_mbuf* mb)
> > +{
> > + return ((uint64_t)((mb)->buf_physaddr + (mb)->data_off));
> > +}
> > +
> > +static inline uint64_t RTE_MBUF_DATA_DMA_ADDR_DEFAULT(struct rte_mbuf
> *mb)
> > +{
> > + return ((uint64_t)((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM));
> > +}
> > +
> I think these names should be made lower case as well.
>
Thanks, I was waiting for one explicit input on this. I have sent v3 patch.
[dpdk-dev] [PATCH v3] Move rte_mbuf macros to common header file
Macros RTE_MBUF_DATA_DMA_ADDR and RTE_MBUF_DATA_DMA_ADDR_DEFAULT
are defined in each PMD driver file. Convert macros to inline
functions and move them to common lib/librte_mbuf/rte_mbuf.h file.
PMD drivers include rte_mbuf.h file directly/indirectly hence no
additionl header file inclusion is necessary.
v3:
> Changed converted macro->inline names to lower-case
> Fix checkpatch.pl errors and warnings
(camelcase warning is not fixed)
> Compiled following targets
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> x86_64-native-bsdapp-gcc
> x86_64-native-bsdapp-clang
> Tested x86_64 ubuntu 14.04
> make test
v2:
> Changed both macros to inline functions in all PMD
> Changed macro to rte_pktmbuf_mtod in xenvirt module
> Compiled following targets
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> Tested x86_64 ubuntu 14.04
> testpmd and make test
v1:
> Move macros into common rte_mbuf header file.
> Compiled for:
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> x86_64-native-bsdapp-gcc
> x86_64-native-bsdapp-clang
Tested on:
> x86_64 Ubuntu 14.04, testpmd and 'make test'
> FreeBSD 10.1, testpmd
Signed-off-by: Ravi Kerur
---
drivers/net/bnx2x/bnx2x.c | 2 +-
drivers/net/bnx2x/bnx2x.h | 3 ---
drivers/net/cxgbe/sge.c| 3 ---
drivers/net/e1000/em_rxtx.c| 15 +--
drivers/net/e1000/igb_rxtx.c | 14 --
drivers/net/i40e/i40e_rxtx.c | 20 +++-
drivers/net/ixgbe/ixgbe_rxtx.c | 14 +++---
drivers/net/ixgbe/ixgbe_rxtx.h | 6 --
drivers/net/virtio/virtio_rxtx.c | 2 +-
drivers/net/virtio/virtqueue.h | 3 ---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 11 +++
drivers/net/xenvirt/virtqueue.h| 5 +
lib/librte_mbuf/rte_mbuf.h | 10 ++
13 files changed, 39 insertions(+), 69 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index fed7a06..a3f118c 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2147,7 +2147,7 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct
rte_mbuf **m_head, int m_p
tx_start_bd = &txq->tx_ring[TX_BD(bd_prod, txq)].start_bd;
tx_start_bd->addr =
- rte_cpu_to_le_64(RTE_MBUF_DATA_DMA_ADDR(m0));
+ rte_cpu_to_le_64(rte_mbuf_data_dma_addr(m0));
tx_start_bd->nbytes = rte_cpu_to_le_16(m0->data_len);
tx_start_bd->bd_flags.as_bitfield = ETH_TX_BD_FLAGS_START_BD;
tx_start_bd->general_data =
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 867b92a..28bd83f 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -141,9 +141,6 @@ struct bnx2x_device_type {
char *bnx2x_name;
};
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- ((uint64_t)((mb)->buf_physaddr + (mb)->data_off))
-
#define BNX2X_PAGE_SHIFT 12
#define BNX2X_PAGE_SIZE(1 << BNX2X_PAGE_SHIFT)
#define BNX2X_PAGE_MASK(~(BNX2X_PAGE_SIZE - 1))
diff --git a/drivers/net/cxgbe/sge.c b/drivers/net/cxgbe/sge.c
index 6eb1244..8f4c025 100644
--- a/drivers/net/cxgbe/sge.c
+++ b/drivers/net/cxgbe/sge.c
@@ -1267,9 +1267,6 @@ static struct rte_mbuf *t4_pktgl_to_mbuf(const struct
pkt_gl *gl)
return t4_pktgl_to_mbuf_usembufs(gl);
}
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- ((dma_addr_t) ((mb)->buf_physaddr + (mb)->data_off))
-
/**
* t4_ethrx_handler - process an ingress ethernet packet
* @q: the response queue that received the packet
diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
index 3b8776d..39c9744 100644
--- a/drivers/net/e1000/em_rxtx.c
+++ b/drivers/net/e1000/em_rxtx.c
@@ -88,12 +88,6 @@ rte_rxmbuf_alloc(struct rte_mempool *mp)
return (m);
}
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
/**
* Structure associated with each descriptor of the RX ring of a RX queue.
*/
@@ -585,7 +579,7 @@ eth_em_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
* Set up Transmit Data Descriptor.
*/
slen = m_seg->data_len;
-
[dpdk-dev] [PATCH v2] Move rte_mbuf macros to common header file
Macros RTE_MBUF_DATA_DMA_ADDR and RTE_MBUF_DATA_DMA_ADDR_DEFAULT
are defined in each PMD driver file. Move those macros into common
lib/librte_mbuf/rte_mbuf.h file. PMD drivers include rte_mbuf.h
file directly/indirectly hence no additionl header file inclusion
is necessary.
v2:
> Changed both macros to inline functions in all PMD
> Changed macro to rte_pktmbuf_mtod in xenvirt module
v1:
> Move macros into common rte_mbuf header file.
Compiled for:
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> x86_64-native-bsdapp-gcc
> x86_64-native-bsdapp-clang
Tested on:
> x86_64 Ubuntu 14.04, testpmd and 'make test'
> FreeBSD 10.1, testpmd
Signed-off-by: Ravi Kerur
---
drivers/net/bnx2x/bnx2x.h | 3 ---
drivers/net/cxgbe/sge.c| 3 ---
drivers/net/e1000/em_rxtx.c| 6 --
drivers/net/e1000/igb_rxtx.c | 6 --
drivers/net/i40e/i40e_rxtx.c | 6 --
drivers/net/ixgbe/ixgbe_rxtx.h | 6 --
drivers/net/virtio/virtqueue.h | 3 ---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 6 --
drivers/net/xenvirt/virtqueue.h| 5 +
lib/librte_mbuf/rte_mbuf.h | 10 ++
10 files changed, 11 insertions(+), 43 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 867b92a..28bd83f 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -141,9 +141,6 @@ struct bnx2x_device_type {
char *bnx2x_name;
};
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- ((uint64_t)((mb)->buf_physaddr + (mb)->data_off))
-
#define BNX2X_PAGE_SHIFT 12
#define BNX2X_PAGE_SIZE(1 << BNX2X_PAGE_SHIFT)
#define BNX2X_PAGE_MASK(~(BNX2X_PAGE_SIZE - 1))
diff --git a/drivers/net/cxgbe/sge.c b/drivers/net/cxgbe/sge.c
index 6eb1244..8f4c025 100644
--- a/drivers/net/cxgbe/sge.c
+++ b/drivers/net/cxgbe/sge.c
@@ -1267,9 +1267,6 @@ static struct rte_mbuf *t4_pktgl_to_mbuf(const struct
pkt_gl *gl)
return t4_pktgl_to_mbuf_usembufs(gl);
}
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- ((dma_addr_t) ((mb)->buf_physaddr + (mb)->data_off))
-
/**
* t4_ethrx_handler - process an ingress ethernet packet
* @q: the response queue that received the packet
diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
index 3b8776d..c7d97c1 100644
--- a/drivers/net/e1000/em_rxtx.c
+++ b/drivers/net/e1000/em_rxtx.c
@@ -88,12 +88,6 @@ rte_rxmbuf_alloc(struct rte_mempool *mp)
return (m);
}
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
/**
* Structure associated with each descriptor of the RX ring of a RX queue.
*/
diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index 19905fd..a217cea 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -88,12 +88,6 @@ rte_rxmbuf_alloc(struct rte_mempool *mp)
return (m);
}
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
/**
* Structure associated with each descriptor of the RX ring of a RX queue.
*/
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index fd656d5..5ba6d27 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -78,12 +78,6 @@
PKT_TX_L4_MASK | \
PKT_TX_OUTER_IP_CKSUM)
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- ((uint64_t)((mb)->buf_physaddr + (mb)->data_off))
-
static const struct rte_memzone *
i40e_ring_dma_zone_reserve(struct rte_eth_dev *dev,
const char *ring_name,
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
index b9eca67..dbb9f00 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.h
+++ b/drivers/net/ixgbe/ixgbe_rxtx.h
@@ -40,12 +40,6 @@
#define RTE_IXGBE_DESCS_PER_LOOP4
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
#ifdef RTE_IXGBE_INC_VECTOR
#define RTE_IXGBE_RXQ_REARM_THRESH 32
#define RTE_IXGBE_MAX_RX_BURST RTE_IXGBE_RXQ_REARM_THRESH
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 7789411..9ea9b96 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -68,9 +68,6 @@ struct rte_mbuf;
#define VIRTQUEUE_MAX_NAME_SZ 32
-#define RTE_MBUF_DATA_DMA_ADDR(mb)
[dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id
Hi Tetsuya, On Mon, Sep 28, 2015 at 8:32 PM, Tetsuya Mukawa wrote: > On 2015/09/24 6:22, Ravi Kerur wrote: > > Hi David, Tetsuya, > > > > I have sent V3 (changes isolated to rte_ether component) for formal > review. > > Please look into it and let me know your inputs. > > Hi Ravi, > > I've checked the patch. > I guess your patch is good. > > > > > @David: I looked at "rte_eth_dev_get_port_by_name()", this function is > > similar to "rte_eth_dev_get_name_by_port" and I have used same logic. Let > > me know if this not correct I can fix both. > > Do you comment about rte_eth_dev_get_port_by_name and > rte_eth_dev_get_port_by_addr? > If so, I guess we don't need to merge. > > I just mentioned that new functions are using same logic as existing function. Thanks, Ravi > > Thanks, > > Ravi > > > > > > On Tue, Sep 15, 2015 at 4:28 AM, Ravi Kerur wrote: > > > >> Hi David, > >> > >> > >> On Thu, Sep 3, 2015 at 7:04 AM, David Marchand < > david.marchand at 6wind.com> > >> wrote: > >> > >>> Hello Ravi, Tetsuya, > >>> > >>> On Tue, Aug 25, 2015 at 7:59 PM, Ravi Kerur wrote: > >>> > >>>> Let us know how you want us to fix this? To fix rte_eal_vdev_init and > >>>> rte_eal_pci_probe_one to return allocated port_id we had 2 approaches > >>>> mentioned in earlier discussion. In addition to those we have another > >>>> approach with changes isolated only to rte_ether component. I am > attaching > >>>> diffs (preliminary) with this email. Please let us know your inputs > since > >>>> it involves EAL component. > >>>> > >>> - This patch looks like a good ethdev cleanup (even if it really lacks > >>> some context / commit log). > >>> > >>> I wonder just why you only take the first part of the name in > >>> rte_eth_dev_get_port_by_name(). > >>> Would not this match, let's say, both toto and toto0 vdevs ? > >>> Is this intended ? > >>> > >>> It was not intended, i will look into it. > >>> - In the end, with this patch, do we still need to update eal ? > >>> Looking at the code, I am not sure anymore. > >>> > >> Approach 3 (preliminary diffs sent as an attachment) doesn't involve EAL > >> but the other two solutions do. So please let us know which one you > prefer. > >> I will send updated patch. > >> > >> Thanks, > >> Ravi > >> > >> > >>> > >>> > >>> -- > >>> David Marchand > >>> > >> > >
[dpdk-dev] [PATCH v1] Move rte_mbuf macros to common header file
Thanks Konstantin. I will send out v2 shortly. On Tue, Sep 29, 2015 at 2:55 AM, Ananyev, Konstantin < konstantin.ananyev at intel.com> wrote: > > Hi Ravi, > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Kerur > > Sent: Saturday, September 26, 2015 3:47 AM > > To: Stephen Hemminger; Olivier Matz > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v1] Move rte_mbuf macros to common header > file > > > > On Thu, Sep 24, 2015 at 4:25 PM, Stephen Hemminger < > > stephen at networkplumber.org> wrote: > > > > > On Thu, 24 Sep 2015 15:50:41 -0700 > > > Ravi Kerur wrote: > > > > > > > Macros RTE_MBUF_DATA_DMA_ADDR and RTE_MBUF_DATA_DMA_ADDR_DEFAULT > > > > are defined in each PMD driver file. Move those macros into common > > > > lib/librte_mbuf/rte_mbuf.h file. All PMD drivers include rte_mbuf.h > > > > file directly/indirectly hence no additionl header file inclusion > > > > is necessary. > > > > > > > > Compiled for: > > > > > x86_64-native-linuxapp-clang > > > > > x86_64-native-linuxapp-gcc > > > > > i686-native-linuxapp-gcc > > > > > x86_64-native-bsdapp-gcc > > > > > x86_64-native-bsdapp-clang > > > > > > > > Tested on: > > > > > x86_64 Ubuntu 14.04, testpmd and 'make test' > > > > > FreeBSD 10.1, testpmd > > > > > > > > Signed-off-by: Ravi Kerur > > > > > > I like the idea, should have been done long ago. > > > > > > My only gripe is that you should do this as inline functions > > > rather than macros. Inline functions are type safe, macros are not. > > > > > > > Agreed. However, I see another variation of the macro, users are > primarily > > from "app" directory and lone user from drivers/net/xenvirt/virtqueue.h > > > > #define RTE_MBUF_DATA_DMA_ADDR(mb) \ > > rte_pktmbuf_mtod(mb, uint64_t) > > > As I can see, it is used only in one place inside xenvirt: > > drivers/net/xenvirt/virtqueue.h:start_dp[idx].addr = > RTE_MBUF_DATA_DMA_ADDR(cookie); > > So we probably can remove that macro definition here and use > rte_pktmbuf_mtod(mb, uint64_t) directly. > > Konstantin > > > > > #define rte_pktmbuf_mtod(m, t) rte_pktmbuf_mtod_offset(m, t, 0) > > > > #define rte_pktmbuf_mtod_offset(m, t, o)\ > > ((t)((char *)(m)->buf_addr + (m)->data_off + (o))) > > > > Let me know should I still go ahead and do inline variation for drivers > or > > use above macro? >
[dpdk-dev] [PATCH v1] Move rte_mbuf macros to common header file
On Thu, Sep 24, 2015 at 4:25 PM, Stephen Hemminger < stephen at networkplumber.org> wrote: > On Thu, 24 Sep 2015 15:50:41 -0700 > Ravi Kerur wrote: > > > Macros RTE_MBUF_DATA_DMA_ADDR and RTE_MBUF_DATA_DMA_ADDR_DEFAULT > > are defined in each PMD driver file. Move those macros into common > > lib/librte_mbuf/rte_mbuf.h file. All PMD drivers include rte_mbuf.h > > file directly/indirectly hence no additionl header file inclusion > > is necessary. > > > > Compiled for: > > > x86_64-native-linuxapp-clang > > > x86_64-native-linuxapp-gcc > > > i686-native-linuxapp-gcc > > > x86_64-native-bsdapp-gcc > > > x86_64-native-bsdapp-clang > > > > Tested on: > > > x86_64 Ubuntu 14.04, testpmd and 'make test' > > > FreeBSD 10.1, testpmd > > > > Signed-off-by: Ravi Kerur > > I like the idea, should have been done long ago. > > My only gripe is that you should do this as inline functions > rather than macros. Inline functions are type safe, macros are not. > Agreed. However, I see another variation of the macro, users are primarily from "app" directory and lone user from drivers/net/xenvirt/virtqueue.h #define RTE_MBUF_DATA_DMA_ADDR(mb) \ rte_pktmbuf_mtod(mb, uint64_t) #define rte_pktmbuf_mtod(m, t) rte_pktmbuf_mtod_offset(m, t, 0) #define rte_pktmbuf_mtod_offset(m, t, o)\ ((t)((char *)(m)->buf_addr + (m)->data_off + (o))) Let me know should I still go ahead and do inline variation for drivers or use above macro?
[dpdk-dev] [PATCH v1] Add support for Intel chipsets
On Fri, Sep 25, 2015 at 1:04 AM, Lu, Wenzhuo wrote: > Hi all, > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Friday, September 25, 2015 3:08 PM > > To: Ravi Kerur > > Cc: dev at dpdk.org; Lu, Wenzhuo > > Subject: Re: [dpdk-dev] [PATCH v1] Add support for Intel chipsets > > > > 2015-09-24 15:13, Ravi Kerur: > > > M. Jay(Jayakumar, Muthurajan) and I > > > discussed and decided to include support for I217/I218 chipsets > > [...] > > > drivers/net/e1000/base/e1000_api.c | 1 + > > > drivers/net/e1000/base/e1000_hw.h | 1 + > > > drivers/net/e1000/base/e1000_ich8lan.c | 30 > +++- > > > drivers/net/e1000/base/e1000_osdep.h| 24 > +++ > > > > You are modifying the base driver which is only allowed by Intel. But > there can > > be exceptions. Wenzhuo, is it an exception? > I'm afraid it's not an exception. We plan to update e1000 base code > recently. Hope it will help. > Thanks. > Ok thanks was not aware of it. Can you let me know what version of e1000/e1000e you plan to update just to make sure it has support for these. Thanks, Ravi
[dpdk-dev] [PATCH v1] Move rte_mbuf macros to common header file
Macros RTE_MBUF_DATA_DMA_ADDR and RTE_MBUF_DATA_DMA_ADDR_DEFAULT
are defined in each PMD driver file. Move those macros into common
lib/librte_mbuf/rte_mbuf.h file. All PMD drivers include rte_mbuf.h
file directly/indirectly hence no additionl header file inclusion
is necessary.
Compiled for:
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> x86_64-native-bsdapp-gcc
> x86_64-native-bsdapp-clang
Tested on:
> x86_64 Ubuntu 14.04, testpmd and 'make test'
> FreeBSD 10.1, testpmd
Signed-off-by: Ravi Kerur
---
drivers/net/bnx2x/bnx2x.h | 3 ---
drivers/net/cxgbe/sge.c| 3 ---
drivers/net/e1000/em_rxtx.c| 6 --
drivers/net/e1000/igb_rxtx.c | 6 --
drivers/net/i40e/i40e_rxtx.c | 6 --
drivers/net/ixgbe/ixgbe_rxtx.h | 6 --
drivers/net/virtio/virtqueue.h | 3 ---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 6 --
lib/librte_mbuf/rte_mbuf.h | 6 ++
9 files changed, 6 insertions(+), 39 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 867b92a..28bd83f 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -141,9 +141,6 @@ struct bnx2x_device_type {
char *bnx2x_name;
};
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- ((uint64_t)((mb)->buf_physaddr + (mb)->data_off))
-
#define BNX2X_PAGE_SHIFT 12
#define BNX2X_PAGE_SIZE(1 << BNX2X_PAGE_SHIFT)
#define BNX2X_PAGE_MASK(~(BNX2X_PAGE_SIZE - 1))
diff --git a/drivers/net/cxgbe/sge.c b/drivers/net/cxgbe/sge.c
index 6eb1244..8f4c025 100644
--- a/drivers/net/cxgbe/sge.c
+++ b/drivers/net/cxgbe/sge.c
@@ -1267,9 +1267,6 @@ static struct rte_mbuf *t4_pktgl_to_mbuf(const struct
pkt_gl *gl)
return t4_pktgl_to_mbuf_usembufs(gl);
}
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- ((dma_addr_t) ((mb)->buf_physaddr + (mb)->data_off))
-
/**
* t4_ethrx_handler - process an ingress ethernet packet
* @q: the response queue that received the packet
diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
index 3b8776d..c7d97c1 100644
--- a/drivers/net/e1000/em_rxtx.c
+++ b/drivers/net/e1000/em_rxtx.c
@@ -88,12 +88,6 @@ rte_rxmbuf_alloc(struct rte_mempool *mp)
return (m);
}
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
/**
* Structure associated with each descriptor of the RX ring of a RX queue.
*/
diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index 19905fd..a217cea 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -88,12 +88,6 @@ rte_rxmbuf_alloc(struct rte_mempool *mp)
return (m);
}
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
/**
* Structure associated with each descriptor of the RX ring of a RX queue.
*/
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index fd656d5..5ba6d27 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -78,12 +78,6 @@
PKT_TX_L4_MASK | \
PKT_TX_OUTER_IP_CKSUM)
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- ((uint64_t)((mb)->buf_physaddr + (mb)->data_off))
-
static const struct rte_memzone *
i40e_ring_dma_zone_reserve(struct rte_eth_dev *dev,
const char *ring_name,
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
index b9eca67..dbb9f00 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.h
+++ b/drivers/net/ixgbe/ixgbe_rxtx.h
@@ -40,12 +40,6 @@
#define RTE_IXGBE_DESCS_PER_LOOP4
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
-#define RTE_MBUF_DATA_DMA_ADDR_DEFAULT(mb) \
- (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
-
#ifdef RTE_IXGBE_INC_VECTOR
#define RTE_IXGBE_RXQ_REARM_THRESH 32
#define RTE_IXGBE_MAX_RX_BURST RTE_IXGBE_RXQ_REARM_THRESH
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 7789411..9ea9b96 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -68,9 +68,6 @@ struct rte_mbuf;
#define VIRTQUEUE_MAX_NAME_SZ 32
-#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- (uint64_t) ((mb)->buf_physaddr + (mb)->data_off)
-
#define VTNET_SQ_RQ_QUEUE_IDX 0
#define VTNET_SQ_TQ_QUEUE_IDX 1
#define VTNET_SQ_CQ_QUEUE_IDX 2
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
b/drivers/net/vmxnet3/
[dpdk-dev] [PATCH v1] Move rte_mbuf macros to common header file
Macros RTE_MBUF_DATA_DMA_ADDR and RTE_MBUF_DATA_DMA_ADDR_DEFAULT are defined in each PMD driver file. Move those macros into common lib/librte_mbuf/rte_mbuf.h file. All PMD drivers include rte_mbuf.h file directly/indirectly hence no additionl header file inclusion is necessary. Ravi Kerur (1): Move rte_buf macros to common header file drivers/net/bnx2x/bnx2x.h | 3 --- drivers/net/cxgbe/sge.c| 3 --- drivers/net/e1000/em_rxtx.c| 6 -- drivers/net/e1000/igb_rxtx.c | 6 -- drivers/net/i40e/i40e_rxtx.c | 6 -- drivers/net/ixgbe/ixgbe_rxtx.h | 6 -- drivers/net/virtio/virtqueue.h | 3 --- drivers/net/vmxnet3/vmxnet3_rxtx.c | 6 -- lib/librte_mbuf/rte_mbuf.h | 6 ++ 9 files changed, 6 insertions(+), 39 deletions(-) -- 1.9.1
[dpdk-dev] [PATCH v1] Add support for I217 and I218 Intel 1G chipsets.
This patch adds I217 and I218 Intel chipsets.
Compiled for:
> i686-native-linuxapp-gcc
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> x86_x32-native-linuxapp-gcc
Tested on:
> x86_64 Ubuntu 14.04 with Intel I218-V and I217-LM chipsets.
Signed-off-by: Ravi Kerur
---
drivers/net/e1000/base/e1000_api.c | 1 +
drivers/net/e1000/base/e1000_hw.h | 1 +
drivers/net/e1000/base/e1000_ich8lan.c | 30 +++-
drivers/net/e1000/base/e1000_osdep.h| 24 +++
drivers/net/e1000/em_ethdev.c | 31 -
lib/librte_eal/common/include/rte_pci_dev_ids.h | 6 +
6 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/net/e1000/base/e1000_api.c
b/drivers/net/e1000/base/e1000_api.c
index a064565..018a9a3 100644
--- a/drivers/net/e1000/base/e1000_api.c
+++ b/drivers/net/e1000/base/e1000_api.c
@@ -292,6 +292,7 @@ s32 e1000_set_mac_type(struct e1000_hw *hw)
case E1000_DEV_ID_PCH_LPT_I217_V:
case E1000_DEV_ID_PCH_LPTLP_I218_LM:
case E1000_DEV_ID_PCH_LPTLP_I218_V:
+ case E1000_DEV_ID_PCH_LPTLP_I218_V2:
mac->type = e1000_pch_lpt;
break;
case E1000_DEV_ID_82575EB_COPPER:
diff --git a/drivers/net/e1000/base/e1000_hw.h
b/drivers/net/e1000/base/e1000_hw.h
index 4dd92a3..c4b6212 100644
--- a/drivers/net/e1000/base/e1000_hw.h
+++ b/drivers/net/e1000/base/e1000_hw.h
@@ -132,6 +132,7 @@ struct e1000_hw;
#define E1000_DEV_ID_PCH_LPT_I217_V0x153B
#define E1000_DEV_ID_PCH_LPTLP_I218_LM 0x155A
#define E1000_DEV_ID_PCH_LPTLP_I218_V 0x1559
+#define E1000_DEV_ID_PCH_LPTLP_I218_V2 0x15A1
#define E1000_DEV_ID_82576 0x10C9
#define E1000_DEV_ID_82576_FIBER 0x10E6
#define E1000_DEV_ID_82576_SERDES 0x10E7
diff --git a/drivers/net/e1000/base/e1000_ich8lan.c
b/drivers/net/e1000/base/e1000_ich8lan.c
index 3b1627b..c7fa1ad 100644
--- a/drivers/net/e1000/base/e1000_ich8lan.c
+++ b/drivers/net/e1000/base/e1000_ich8lan.c
@@ -1386,29 +1386,15 @@ STATIC s32 e1000_check_for_copper_link_ich8lan(struct
e1000_hw *hw)
if (!mac->get_link_status)
return E1000_SUCCESS;
- if ((hw->mac.type < e1000_pch_lpt) ||
- (hw->device_id == E1000_DEV_ID_PCH_LPT_I217_LM) ||
- (hw->device_id == E1000_DEV_ID_PCH_LPT_I217_V)) {
- /* First we want to see if the MII Status Register reports
-* link. If so, then we want to get the current speed/duplex
-* of the PHY.
-*/
- ret_val = e1000_phy_has_link_generic(hw, 1, 0, &link);
- if (ret_val)
- return ret_val;
- } else {
- /* Check the MAC's STATUS register to determine link state
-* since the PHY could be inaccessible while in ULP mode.
-*/
- link = !!(E1000_READ_REG(hw, E1000_STATUS) & E1000_STATUS_LU);
- if (link)
- ret_val = e1000_disable_ulp_lpt_lp(hw, false);
- else
- ret_val = e1000_enable_ulp_lpt_lp(hw, false);
+ /* First we want to see if the MII Status Register reports
+* link. If so, then we want to get the current speed/duplex
+* of the PHY.
+*/
+ ret_val = e1000_phy_has_link_generic(hw, PHY_FORCE_LIMIT, 10,
&link);
+ if (ret_val)
+ return ret_val;
- if (ret_val)
- return ret_val;
- }
+ DEBUGOUT1("After phy_has_link_generic link state is %d\n", link);
if (hw->mac.type == e1000_pchlan) {
ret_val = e1000_k1_gig_workaround_hv(hw, link);
diff --git a/drivers/net/e1000/base/e1000_osdep.h
b/drivers/net/e1000/base/e1000_osdep.h
index d04ec73..3255d37 100644
--- a/drivers/net/e1000/base/e1000_osdep.h
+++ b/drivers/net/e1000/base/e1000_osdep.h
@@ -96,13 +96,22 @@ typedef int bool;
#define E1000_PCI_REG(reg) (*((volatile uint32_t *)(reg)))
+#define E1000_PCI_REG16(reg) (*((volatile uint16_t *)(reg)))
+
#define E1000_PCI_REG_WRITE(reg, value) do { \
E1000_PCI_REG((reg)) = (rte_cpu_to_le_32(value)); \
} while (0)
+#define E1000_PCI_REG_WRITE16(reg, value) do { \
+ E1000_PCI_REG16((reg)) = (value); \
+} while (0)
+
#define E1000_PCI_REG_ADDR(hw, reg) \
((volatile uint32_t *)((char *)(hw)->hw_addr + (reg)))
+#define E1000_PCI_REG_FLASH_ADDR(hw, reg) \
+ ((volatile uint32_t *)((char *)(hw)->flash_address + (reg)))
+
#define E1000_PCI_REG_ARRAY_ADDR(hw, reg, index) \
E1000_PCI_REG_ADDR((hw), (reg) + ((index) << 2))
@@ -111,6 +120,11 @@ static inline uint32_t e1000_read_addr(volatile void* addr)
return rte_le_to_cpu_32(E1000_PCI_RE
[dpdk-dev] [PATCH v1] Add support for Intel chipsets
M. Jay(Jayakumar, Muthurajan) and I discussed and decided to include support for I217/I218 chipsets since these chipsets are found everywhere f.e. on laptops, low-end servers and we found it useful and helpful for testing simple functionality. Hence we decided to send this patch to be included in the mainline. Ravi Kerur (1): Add support for I217 and I218 Intel 1G chipsets. drivers/net/e1000/base/e1000_api.c | 1 + drivers/net/e1000/base/e1000_hw.h | 1 + drivers/net/e1000/base/e1000_ich8lan.c | 30 +++- drivers/net/e1000/base/e1000_osdep.h| 24 +++ drivers/net/e1000/em_ethdev.c | 31 - lib/librte_eal/common/include/rte_pci_dev_ids.h | 6 + 6 files changed, 65 insertions(+), 28 deletions(-) -- 1.9.1
[dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id
Hi David, Tetsuya, I have sent V3 (changes isolated to rte_ether component) for formal review. Please look into it and let me know your inputs. @David: I looked at "rte_eth_dev_get_port_by_name()", this function is similar to "rte_eth_dev_get_name_by_port" and I have used same logic. Let me know if this not correct I can fix both. Thanks, Ravi On Tue, Sep 15, 2015 at 4:28 AM, Ravi Kerur wrote: > Hi David, > > > On Thu, Sep 3, 2015 at 7:04 AM, David Marchand > wrote: > >> Hello Ravi, Tetsuya, >> >> On Tue, Aug 25, 2015 at 7:59 PM, Ravi Kerur wrote: >> >>> Let us know how you want us to fix this? To fix rte_eal_vdev_init and >>> rte_eal_pci_probe_one to return allocated port_id we had 2 approaches >>> mentioned in earlier discussion. In addition to those we have another >>> approach with changes isolated only to rte_ether component. I am attaching >>> diffs (preliminary) with this email. Please let us know your inputs since >>> it involves EAL component. >>> >> >> - This patch looks like a good ethdev cleanup (even if it really lacks >> some context / commit log). >> >> I wonder just why you only take the first part of the name in >> rte_eth_dev_get_port_by_name(). >> Would not this match, let's say, both toto and toto0 vdevs ? >> Is this intended ? >> >> It was not intended, i will look into it. > >> >> - In the end, with this patch, do we still need to update eal ? >> Looking at the code, I am not sure anymore. >> > > Approach 3 (preliminary diffs sent as an attachment) doesn't involve EAL > but the other two solutions do. So please let us know which one you prefer. > I will send updated patch. > > Thanks, > Ravi > > >> >> >> >> -- >> David Marchand >> > >
[dpdk-dev] [PATCH v3] Change rte_eal_vdev_init to update port_id
v3:
> Isolate changes within rte_ether component.
v2:
> Remove tilegx changes
> Use rte_eal_compare_pci_addr for address comparison
> Use dpdk_2.2 in version map file for new functions
v1:
Changes include
> Modify rte_eal_vdev_init to return allocated port_id
> Modify rte_eal_probe_one to return allocated port_id
2. Removed following functions
> rte_eth_dev_save and
> rte_eth_dev_get_changed_port
3. Added 2 new functions
> rte_eth_dev_get_port_by_name
> rte_eth_dev_get_port_by_addr
4. Fix return error(ENOMEM) in function rte_pmd_mpipe_devinit
Compiled on Linux for following targets
> x86_64-native-linuxapp-gcc
> x86_64-native-linuxapp-clang
> x86_x32-native-linuxapp-gcc
Compiled on FreeBSD for following targets
> x86_64-native-bsdapp-clang
> x86_64-native-bsdapp-gcc
Tested on Linux/FreeBSD:
> port attach eth_null
> port start all
> port stop all
> port close all
> port detach 0
> port attach eth_null
> port start all
> port stop all
> port close all
> port detach 0
Successful run of checkpatch.pl on the diffs
Successful validate_abi on Linux for following targets
> x86_64-native-linuxapp-gcc
> x86_64-native-linuxapp-clang
Signed-off-by: Ravi Kerur
---
lib/librte_ether/rte_ethdev.c | 116 +++---
1 file changed, 63 insertions(+), 53 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index b309309..e4b8e41 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -442,32 +442,6 @@ rte_eth_dev_get_device_type(uint8_t port_id)
}
static int
-rte_eth_dev_save(struct rte_eth_dev *devs, size_t size)
-{
- if ((devs == NULL) ||
- (size != sizeof(struct rte_eth_dev) * RTE_MAX_ETHPORTS))
- return -EINVAL;
-
- /* save current rte_eth_devices */
- memcpy(devs, rte_eth_devices, size);
- return 0;
-}
-
-static int
-rte_eth_dev_get_changed_port(struct rte_eth_dev *devs, uint8_t *port_id)
-{
- if ((devs == NULL) || (port_id == NULL))
- return -EINVAL;
-
- /* check which port was attached or detached */
- for (*port_id = 0; *port_id < RTE_MAX_ETHPORTS; (*port_id)++, devs++) {
- if (rte_eth_devices[*port_id].attached ^ devs->attached)
- return 0;
- }
- return -ENODEV;
-}
-
-static int
rte_eth_dev_get_addr_by_port(uint8_t port_id, struct rte_pci_addr *addr)
{
VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
@@ -501,6 +475,59 @@ rte_eth_dev_get_name_by_port(uint8_t port_id, char *name)
}
static int
+rte_eth_dev_get_port_by_name(const char *name, uint8_t *port_id)
+{
+ int i;
+
+ if (name == NULL) {
+ PMD_DEBUG_TRACE("Null pointer is specified\n");
+ return -EINVAL;
+ }
+
+ *port_id = RTE_MAX_ETHPORTS;
+
+ for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+
+ if (!strncmp(name,
+ rte_eth_dev_data[i].name, strlen(name))) {
+
+ *port_id = i;
+
+ return 0;
+ }
+ }
+ return -ENODEV;
+}
+
+static int
+rte_eth_dev_get_port_by_addr(const struct rte_pci_addr *addr, uint8_t *port_id)
+{
+ int i;
+ struct rte_pci_device *pci_dev = NULL;
+
+ if (addr == NULL) {
+ PMD_DEBUG_TRACE("Null pointer is specified\n");
+ return -EINVAL;
+ }
+
+ *port_id = RTE_MAX_ETHPORTS;
+
+ for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+
+ pci_dev = rte_eth_devices[i].pci_dev;
+
+ if (pci_dev &&
+ !rte_eal_compare_pci_addr(&pci_dev->addr, addr)) {
+
+ *port_id = i;
+
+ return 0;
+ }
+ }
+ return -ENODEV;
+}
+
+static int
rte_eth_dev_is_detachable(uint8_t port_id)
{
uint32_t drv_flags;
@@ -530,30 +557,19 @@ rte_eth_dev_is_detachable(uint8_t port_id)
static int
rte_eth_dev_attach_pdev(struct rte_pci_addr *addr, uint8_t *port_id)
{
- uint8_t new_port_id;
- struct rte_eth_dev devs[RTE_MAX_ETHPORTS];
-
if ((addr == NULL) || (port_id == NULL))
goto err;
- /* save current port status */
- if (rte_eth_dev_save(devs, sizeof(devs)))
- goto err;
/* re-construct pci_device_list */
if (rte_eal_pci_scan())
goto err;
- /* invoke probe func of the driver can handle the new device.
-* TODO:
-* rte_eal_pci_probe_one() should return port_id.
-* And rte_eth_dev_save() and rte_eth_dev_get_changed_port()
-* should be removed. */
+ /* Invoke probe func of the driver can handle the new device. */
if (rte_eal_pci_probe_one(addr))
[dpdk-dev] [PATCH v3] Send updated port_id in vdev_init functions
Instead of executing following functions before and after vdev_init > rte_eth_dev_save and > rte_eth_dev_get_changed_port update following functions to return allocated port_id. > rte_eal_vdev_init > rte_eal_probe_one Ravi Kerur (1): Change rte_eal_vdev_init to update port_id lib/librte_ether/rte_ethdev.c | 116 +++--- 1 file changed, 63 insertions(+), 53 deletions(-) -- 1.9.1
[dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id
Hi David, On Thu, Sep 3, 2015 at 7:04 AM, David Marchand wrote: > Hello Ravi, Tetsuya, > > On Tue, Aug 25, 2015 at 7:59 PM, Ravi Kerur wrote: > >> Let us know how you want us to fix this? To fix rte_eal_vdev_init and >> rte_eal_pci_probe_one to return allocated port_id we had 2 approaches >> mentioned in earlier discussion. In addition to those we have another >> approach with changes isolated only to rte_ether component. I am attaching >> diffs (preliminary) with this email. Please let us know your inputs since >> it involves EAL component. >> > > - This patch looks like a good ethdev cleanup (even if it really lacks > some context / commit log). > > I wonder just why you only take the first part of the name in > rte_eth_dev_get_port_by_name(). > Would not this match, let's say, both toto and toto0 vdevs ? > Is this intended ? > > It was not intended, i will look into it. > > - In the end, with this patch, do we still need to update eal ? > Looking at the code, I am not sure anymore. > Approach 3 (preliminary diffs sent as an attachment) doesn't involve EAL but the other two solutions do. So please let us know which one you prefer. I will send updated patch. Thanks, Ravi > > > > -- > David Marchand >
[dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id
Hi Thomas, David Let us know how you want us to fix this? To fix rte_eal_vdev_init and rte_eal_pci_probe_one to return allocated port_id we had 2 approaches mentioned in earlier discussion. In addition to those we have another approach with changes isolated only to rte_ether component. I am attaching diffs (preliminary) with this email. Please let us know your inputs since it involves EAL component. Thanks, Ravi On Thu, Aug 20, 2015 at 8:33 PM, Tetsuya Mukawa wrote: > On 2015/08/21 4:16, Ravi Kerur wrote: > > > > > /** > > > * Uninitalize a driver specified by name. > > > @@ -125,6 +127,38 @@ int rte_eal_vdev_init(const char *name, > > const char *args); > > > */ > > > int rte_eal_vdev_uninit(const char *name); > > > > > > +/** > > > + * Given name, return port_id associated with the device. > > > + * > > > + * @param name > > > + * Name associated with device. > > > + * @param port_id > > > + * The port identifier of the device. > > > + * > > > + * @return > > > + * - 0: Success. > > > + * - -EINVAL: NULL string (name) > > > + * - -ENODEV failure > > > > Please define above in 'rte_ethdev.h.' > > > > > > Hi Tetsuya, > > > > I would like to take a step back and explain why function declarations > > are in rte_dev.h and not in rte_ethdev.h > > > > Approach 1: > > Initially I thought of modifying driver init routine to return/update > > port_id as the init routine is the place port_id gets allocated and it > > would have been clean approach. However, it required changes to all > > PMD_VDEV driver init routine to modify function signature for the > > changes which I thought may be an overkill. > > > > Approach 2: > > Instead I chose to define 2 functions in librte_ether/rte_ethdev.c and > > make use of it. In this approach new functions are invoked from > > librte_eal/common/.c to get port_id. If I had new function > > declarations in rte_ethdev.h and included that file in > > librte_eal/common/.c files it creates circular dependancy and > > compilation fails, hence I took hybrid approach of definitions in > > librte_ether and declarations in librte_eal. > > > > Please let me know if there is a better approach to take care of your > > comments. As it stands declarations cannot be moved to rte_ethdev.h > > for compilation reasons. > > > > Thanks, > > Ravi > > > > Hi Ravi, > (Adding David) > > I appreciate your description. I understand why you define the functions > in rte_dev.h. > > About Approach2, I don't know a way to implement cleanly. > I guess if we define the functions in rte_dev.h, the developers who want > to use the functions will be confused because the functions are > implemented in ethdev.c, but it is needed to include rte_dev.h. > > To avoid such a confusion, following implementation might be worked, but > I am not sure this cording style is allowed in eal library. > > > Define the functions in rte_ethdev.h, then fix librte_eal/common/.c > files like below > > ex) lib/librte_eal/common/eal_common_dev.c > > +#include > #include > #include > #include > > #include "eal_private.h" > > +extern int rte_eth_dev_get_port_by_name(const char *name, uint8_t > *port_id); > +extern int rte_eth_dev_get_port_by_addr(const struct rte_pci_addr > *addr, uint8_t *port_id); > > > In this case, the developer might be able to notice that above usage in > eal library is some kind of exception. But I guess the DPDK code won't > be clean if we start having a exception. > So it might be good to choose Approach1, because apparently it is > straight forward. > Anyone won't be confused and complained about coding style. > > > Hi David, > > Could you please let us know what you think? > Do you have a good approach for this? > > Thanks, > Tetsuya > >
[dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id
On Wed, Aug 19, 2015 at 7:07 PM, Tetsuya Mukawa wrote:
> On 2015/08/20 4:42, Ravi Kerur wrote:
> > v2:
> >> Remove rte_pmd_mpipe_devinit changes
> >> Use rte_eal_compare_pci_addr for address comparison
> >> Use dpdk_2.2 in version map file for new functions
> >
> > v1:
> > Changes include
> >> Modify rte_eal_vdev_init to return allocated port_id
> >> Modify rte_eal_probe_one to return allocated port_id
> >
> > 2. Removed following functions
> >> rte_eth_dev_save and
> >> rte_eth_dev_get_changed_port
> >
> > 3. Added 2 new functions
> >> rte_eth_dev_get_port_by_name
> >> rte_eth_dev_get_port_by_addr
> >
> > 4. Fix return error(ENOMEM) in function rte_pmd_mpipe_devinit
> >
> > Compiled on Linux for following targets
> >> x86_64-native-linuxapp-gcc
> >> x86_64-native-linuxapp-clang
> >> x86_x32-native-linuxapp-gcc
> >
> > Compiled on FreeBSD for following targets
> >> x86_64-native-bsdapp-clang
> >> x86_64-native-bsdapp-gcc
> >
> > Tested on Linux/FreeBSD:
> >> port attach eth_null
> >> port start all
> >> port stop all
> >> port close all
> >> port detach 0
> >> port attach eth_null
> >> port start all
> >> port stop all
> >> port close all
> >> port detach 0
> >
> > Successful run of checkpatch.pl on the diffs
> >
> > Successful validate_abi on Linux for following targets
> >
> >> x86_64-native-linuxapp-gcc
> >> x86_64-native-linuxapp-clang
> >
> > Signed-off-by: Ravi Kerur
> > ---
> > drivers/net/enic/enic_ethdev.c | 2 +-
> > lib/librte_eal/common/eal_common_dev.c | 13 ++--
> > lib/librte_eal/common/eal_common_pci.c | 6 +-
> > lib/librte_eal/common/include/rte_dev.h | 36 +-
> > lib/librte_eal/common/include/rte_pci.h | 4 +-
> > lib/librte_ether/rte_ethdev.c | 122
> +---
> > lib/librte_ether/rte_ether_version.map | 8 +++
> > 7 files changed, 125 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/net/enic/enic_ethdev.c
> b/drivers/net/enic/enic_ethdev.c
> > index 8280cea..472ef5a 100644
> > --- a/drivers/net/enic/enic_ethdev.c
> > +++ b/drivers/net/enic/enic_ethdev.c
> > @@ -36,8 +36,8 @@
> > #include
> > #include
> >
> > -#include
> > #include
> > +#include
> > #include
> > #include
> >
> > diff --git a/lib/librte_eal/common/eal_common_dev.c
> b/lib/librte_eal/common/eal_common_dev.c
> > index 4089d66..ffdb3b5 100644
> > --- a/lib/librte_eal/common/eal_common_dev.c
> > +++ b/lib/librte_eal/common/eal_common_dev.c
> > @@ -37,6 +37,7 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -64,7 +65,7 @@ rte_eal_driver_unregister(struct rte_driver *driver)
> > }
> >
> > int
> > -rte_eal_vdev_init(const char *name, const char *args)
> > +rte_eal_vdev_init(const char *name, const char *args, uint8_t *port_id)
> > {
> > struct rte_driver *driver;
> >
> > @@ -81,8 +82,12 @@ rte_eal_vdev_init(const char *name, const char *args)
> >* will be "eth_pcap", but "name" will be "eth_pcapN".
> >* So use strncmp to compare.
> >*/
> > - if (!strncmp(driver->name, name, strlen(driver->name)))
> > - return driver->init(name, args);
> > + if (!strncmp(driver->name, name, strlen(driver->name))) {
> > + if (!driver->init(name, args))
> > + return rte_eth_dev_get_port_by_name(
> > + name, port_id);
> > + }
> > +
>
> Please remove needless line.
>
> > }
> >
> > RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
> > @@ -108,7 +113,7 @@ rte_eal_dev_init(void)
> > continue;
> >
> > if (rte_eal_vdev_init(devargs->virtual.drv_name,
> > - devargs->args)) {
> > + devargs->args, NULL)) {
> > RTE_LOG(ERR, EAL, "failed to initialize %s
> device\n",
> >
[dpdk-dev] [PATCH v2] Move common functions in eal_thread.c
v2:
> Remove un-needed header file eal_private.h from freeBSD
eal_thread.c after code movement.
v1:
Changes include
> Moving common functions in eal_thread.c in
linuxapp and bsdapp into common/eal_common_thread.c file.
> Rearrange eal_common_thread.c compilation in Makefile
for ABI.
Compiled successfully for following targets
> x86_64-native-linuxapp-clang
> x86_64-native-linuxapp-gcc
> x86_x32-native-linuxapp-gcc
> i686-native-linuxapp-gcc
> x86_64-native-bsdapp-clang
> x86_64-native-bsdapp-gcc
Tested on
> Ubuntu 14.04, testpmd functionality
> FreeBSD 10.1, testpmd functionality
Signed-off-by: Ravi Kerur
---
lib/librte_eal/bsdapp/eal/Makefile| 3 +-
lib/librte_eal/bsdapp/eal/eal_thread.c| 153 --
lib/librte_eal/common/eal_common_thread.c | 147 +++-
lib/librte_eal/linuxapp/eal/Makefile | 3 +-
lib/librte_eal/linuxapp/eal/eal_thread.c | 153 --
5 files changed, 150 insertions(+), 309 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index a969435..93d76bb 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -51,6 +51,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) := eal.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_memory.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_hugepage_info.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_thread.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_thread.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_log.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_pci.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_debug.c
@@ -76,7 +77,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_hexdump.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_devargs.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_dev.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_options.c
-SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_thread.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += rte_malloc.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += malloc_elem.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += malloc_heap.c
@@ -90,6 +90,7 @@ CFLAGS_eal_common_log.o := -D_GNU_SOURCE
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
CFLAGS_eal_thread.o += -Wno-return-type
+CFLAGS_eal_common_thread.o += -Wno-return-type
CFLAGS_eal_hpet.o += -Wno-return-type
endif
diff --git a/lib/librte_eal/bsdapp/eal/eal_thread.c
b/lib/librte_eal/bsdapp/eal/eal_thread.c
index 9a03437..4036d21 100644
--- a/lib/librte_eal/bsdapp/eal/eal_thread.c
+++ b/lib/librte_eal/bsdapp/eal/eal_thread.c
@@ -35,163 +35,10 @@
#include
#include
#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "eal_private.h"
#include "eal_thread.h"
-RTE_DEFINE_PER_LCORE(unsigned, _lcore_id) = LCORE_ID_ANY;
-RTE_DEFINE_PER_LCORE(unsigned, _socket_id) = (unsigned)SOCKET_ID_ANY;
-RTE_DEFINE_PER_LCORE(rte_cpuset_t, _cpuset);
-
-/*
- * Send a message to a slave lcore identified by slave_id to call a
- * function f with argument arg. Once the execution is done, the
- * remote lcore switch in FINISHED state.
- */
-int
-rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
-{
- int n;
- char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
-
- if (lcore_config[slave_id].state != WAIT)
- return -EBUSY;
-
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
-
- /* send message */
- n = 0;
- while (n == 0 || (n < 0 && errno == EINTR))
- n = write(m2s, &c, 1);
- if (n < 0)
- rte_panic("cannot write on configuration pipe\n");
-
- /* wait ack */
- do {
- n = read(s2m, &c, 1);
- } while (n < 0 && errno == EINTR);
-
- if (n <= 0)
- rte_panic("cannot read on configuration pipe\n");
-
- return 0;
-}
-
-/* set affinity for current thread */
-static int
-eal_thread_set_affinity(void)
-{
- unsigned lcore_id = rte_lcore_id();
-
- /* acquire system unique id */
- rte_gettid();
-
- /* update EAL thread core affinity */
- return rte_thread_set_affinity(&lcore_config[lcore_id].cpuset);
-}
-
-void eal_thread_init_master(unsigned lcore_id)
-{
- /* set the lcore ID in per-lcore memory area */
- RTE_PER_LCORE(_lcore_id) = lcore_id;
-
- /* set CPU affinity */
- if (eal_thread_set_affinity() < 0)
- rte_panic("cannot set affinity\n");
-}
-
-/* main loop of threads */
-__attribute__((noreturn)) void *
-eal_thre
[dpdk-dev] [PATCH v1] Return ENOMEM during mpipe_devinit failure
In function rte_pmd_mpipe_devinit, if rte_eth_dev_allocate
fails return error which is inline with other drivers.
Signed-off-by: Ravi Kerur
---
drivers/net/mpipe/mpipe_tilegx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index 743feef..6e3e304 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -1582,6 +1582,7 @@ rte_pmd_mpipe_devinit(const char *ifname,
if (!eth_dev) {
RTE_LOG(ERR, PMD, "%s: Failed to allocate device.\n", ifname);
rte_free(priv);
+ return -ENOMEM;
}
RTE_LOG(INFO, PMD, "%s: Initialized mpipe device"
--
1.9.1
[dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id
v2:
> Remove rte_pmd_mpipe_devinit changes
> Use rte_eal_compare_pci_addr for address comparison
> Use dpdk_2.2 in version map file for new functions
v1:
Changes include
> Modify rte_eal_vdev_init to return allocated port_id
> Modify rte_eal_probe_one to return allocated port_id
2. Removed following functions
> rte_eth_dev_save and
> rte_eth_dev_get_changed_port
3. Added 2 new functions
> rte_eth_dev_get_port_by_name
> rte_eth_dev_get_port_by_addr
4. Fix return error(ENOMEM) in function rte_pmd_mpipe_devinit
Compiled on Linux for following targets
> x86_64-native-linuxapp-gcc
> x86_64-native-linuxapp-clang
> x86_x32-native-linuxapp-gcc
Compiled on FreeBSD for following targets
> x86_64-native-bsdapp-clang
> x86_64-native-bsdapp-gcc
Tested on Linux/FreeBSD:
> port attach eth_null
> port start all
> port stop all
> port close all
> port detach 0
> port attach eth_null
> port start all
> port stop all
> port close all
> port detach 0
Successful run of checkpatch.pl on the diffs
Successful validate_abi on Linux for following targets
> x86_64-native-linuxapp-gcc
> x86_64-native-linuxapp-clang
Signed-off-by: Ravi Kerur
---
drivers/net/enic/enic_ethdev.c | 2 +-
lib/librte_eal/common/eal_common_dev.c | 13 ++--
lib/librte_eal/common/eal_common_pci.c | 6 +-
lib/librte_eal/common/include/rte_dev.h | 36 +-
lib/librte_eal/common/include/rte_pci.h | 4 +-
lib/librte_ether/rte_ethdev.c | 122 +---
lib/librte_ether/rte_ether_version.map | 8 +++
7 files changed, 125 insertions(+), 66 deletions(-)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 8280cea..472ef5a 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -36,8 +36,8 @@
#include
#include
-#include
#include
+#include
#include
#include
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common/eal_common_dev.c
index 4089d66..ffdb3b5 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -37,6 +37,7 @@
#include
#include
+#include
#include
#include
#include
@@ -64,7 +65,7 @@ rte_eal_driver_unregister(struct rte_driver *driver)
}
int
-rte_eal_vdev_init(const char *name, const char *args)
+rte_eal_vdev_init(const char *name, const char *args, uint8_t *port_id)
{
struct rte_driver *driver;
@@ -81,8 +82,12 @@ rte_eal_vdev_init(const char *name, const char *args)
* will be "eth_pcap", but "name" will be "eth_pcapN".
* So use strncmp to compare.
*/
- if (!strncmp(driver->name, name, strlen(driver->name)))
- return driver->init(name, args);
+ if (!strncmp(driver->name, name, strlen(driver->name))) {
+ if (!driver->init(name, args))
+ return rte_eth_dev_get_port_by_name(
+ name, port_id);
+ }
+
}
RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
@@ -108,7 +113,7 @@ rte_eal_dev_init(void)
continue;
if (rte_eal_vdev_init(devargs->virtual.drv_name,
- devargs->args)) {
+ devargs->args, NULL)) {
RTE_LOG(ERR, EAL, "failed to initialize %s device\n",
devargs->virtual.drv_name);
return -1;
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 16e8629..3d97892 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -79,6 +79,7 @@
#include
#include
#include
+#include
#include "eal_private.h"
@@ -322,7 +323,7 @@ pci_detach_all_drivers(struct rte_pci_device *dev)
* the driver of the devive.
*/
int
-rte_eal_pci_probe_one(const struct rte_pci_addr *addr)
+rte_eal_pci_probe_one(const struct rte_pci_addr *addr, uint8_t *port_id)
{
struct rte_pci_device *dev = NULL;
int ret = 0;
@@ -337,7 +338,8 @@ rte_eal_pci_probe_one(const struct rte_pci_addr *addr)
ret = pci_probe_all_drivers(dev);
if (ret < 0)
goto err_return;
- return 0;
+
+ return rte_eth_dev_get_port_by_addr(addr, port_id);
}
return -1;
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index f601d21..564cdf3 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -110,10 +110,12 @@ int rte_eal_dev_i
