[dpdk-dev] Question on VMDq mode
Hi,
last week I sent a question about VMDq and I did not get any reply.
Today I'll be more generic rather than last time, and I hope someone will
clarify my ideas.
Through the DPDK framework, is it possible to make a pre-filter based on some
header parameter directly on the NIC (in addition to those on vlan id and vlan
priority used in the example applications)?
I already tried to use these functions:
1) rte_eth_dev_mac_addr_add : I used it with the NIC configured in VMDq mode
static const struct rte_eth_conf port_conf = {
.rxmode = {
.mq_mode= ETH_MQ_RX_VMDQ_ONLY,
.split_hdr_size = 0,
.header_split = 0, /**< Header Split disabled */
.hw_ip_checksum = 1, /**< IP checksum offload disabled */
.hw_vlan_filter = 0, /**< VLAN filtering disabled */
.jumbo_frame= 0, /**< Jumbo Frame Support disabled */
.hw_strip_crc = 0,
},
.txmode = {
.mq_mode = ETH_MQ_TX_NONE,
},
.rx_adv_conf = {
.vmdq_rx_conf = {
.nb_queue_pools = ETH_64_POOLS,
.enable_default_pool = 1,
.default_pool = 0,
},
},
};
When I use the function above, the NIC discards all the packets with MAC source
address different from one of those I added with the function itself; moreover,
I receive this packets only if I enable the default pool in the configuration
phase (otherwise no packet is received).
2) rte_eth_dev_fdir_add_signature_filter: this time I used another
configuration for the device, but I think I do some mistake (it is so bad do
not having a good doc about this stuff)
.rxmode = {
.mq_mode= ETH_MQ_RX_NONE,
.split_hdr_size = 0,
.header_split = 0, /**< Header Split disabled */
.hw_ip_checksum = 1, /**< IP checksum offload disabled */
.hw_vlan_filter = 0, /**< VLAN filtering disabled */
.jumbo_frame= 0, /**< Jumbo Frame Support disabled */
.hw_strip_crc = 0,
},
.txmode = {
.mq_mode = ETH_MQ_TX_NONE,
},
.fdir_conf = {
.mode = RTE_FDIR_MODE_SIGNATURE ,
.pballoc = RTE_FDIR_PBALLOC_64K ,
.status = RTE_FDIR_NO_REPORT_STATUS ,
.flexbytes_offset = 0,
.drop_queue = 0,
},
};
In this way, the device does not start, although it is a x540 (hence it should
support the FDIR_MODE_SIGNATURE).
Regards,
Mauro
> Date: Wed, 4 Dec 2013 19:28:39 +0100
> From: mauroannarumma at hotmail.it
> To: dev at dpdk.org
> Subject: [dpdk-dev] Question on VMDq mode
>
> Hi,
> I'm trying to use the VMDq technology for pre-filter packets on the
> NIC;unfortunately I found only two examples about this, and both express
> conditions on the VLAN tag, while I need to select packets based on
> their (source) MAC address.
> After looking to the API, I find out the function
> *rte_eth_dev_mac_addr_add*, which requires the parameter *uint32_t pool*
> (VMDq pool index to associate address with (if VMDq is enabled)).
>
> My questions are:
> 1) Am I on the right way to achieve my goal?
> 2) How is it realized the mapping pools/queues?
>
> Regards,
>
> Mauro
[dpdk-dev] Issues on FDIR and multi-processes
Hi everyone, we are working with Flow DIRector on a multiprocess application. This application consists of N secondary processes, each one receiving packets directly from its own queue on the NIC. It works fine when each secondary process runs on a different CPU core; instead, if we try to run two secondary processes on the same CPU core, these processes aren't able to read from their respectively queue. Moreover we observe that one process initially receives same packet; then all the processes no longer receive anything. Do you have any suggestion about these strange behaviour? Is it a DPDK limitation or a FDIR limitation? Best regards. Mauro
[dpdk-dev] FW: Issues on FDIR and multi-processes
Hi Bruce, thanks for the reply; I'm trying to do what you suggest, in particular I set the value of the lcore_id variable with this instruction: RTE_PER_LCORE(_lcore_id) = temp_lcore_id; where temp_lcore_id is a unique id strictly less then RTE_MAX_LCORE; the instruction is placed just after the "rte_eal_init" call in my main function. I still have the same problem whit the secondary processes. Do you think there could be other issues with the secondary-processes on the some core? Did I do something wrong in the _lcore_id setting? Regards. Mauro > From: bruce.richardson at intel.com > To: mauroannarumma at hotmail.it; dev at dpdk.org > Subject: RE: [dpdk-dev] Issues on FDIR and multi-processes > Date: Wed, 2 Apr 2014 15:33:09 + > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mauro Annarumma > > Sent: Wednesday, April 02, 2014 4:02 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] Issues on FDIR and multi-processes > > > > Hi everyone, > > we are working with Flow DIRector on a multiprocess application. This > > application consists of N secondary processes, > > each one receiving packets directly from its own queue on the NIC. It works > > fine when each secondary process runs on > > a different CPU core; instead, if we try to run two secondary processes on > > the same CPU core, these processes aren't > > able to read from their respectively queue. > > Running two co-operating Intel DPDK processes on the same lcore is not a > supported configuration of Intel DPDK multiprocess. [Please see section 20.3 > of the Intel DPDK Programmer's Guide document, which lists out some > limitations of multi-process support]. Basically, each process in a > multiprocess configuration is equivalent to a thread in a normal application > deployment, so just as having two threads on the same core causes problems > with mempools and other objects which use an "lcore_id" value unique in each > thread to work correctly, so running two processes on the same lcore can > cause exactly the same issues. > If you really do want to use this model and have multiple threads on the same > lcore, at minimum you need to ensure that each thread/process has a unique > lcore_id value <= RTE_MAX_LCORE. > > /Bruce
[dpdk-dev] Is Flow Director supported on the x540 chipset?
Hi, I'm trying to use Flow Director. Initially I used a X540 chipset and I was not able to make it work; I thought it was a compatibility problem with the controller. Maxime suggested to change some lines in the ixgbe_fdir.c file, I changed these lines but it did not give the expected results; At this point I was sure that the problem was the incompatibility between the DPDK and the X540 chipset therefore I retrived a NIC whit a 82599 chipset and I repeated my attempts, unfortunately I got the some problems. In order to be more clear I explain my attempts: I try to run the test-pmd app with the command-line option "--pkt-filter-mode=perfect", the app doesn't start (the rte_eth_dev_start function return an error) otherwise without the --pkt-filter-mode command-line option the application run normally. This is the command line I use to start the program: frog at frog:~/dpdk-1.5.2r1/app/test-pmd$ sudo ./testpmd -c 0x0f -n 2 -m 512 -- -i --portmask=0x3 --nb-cores=2 --pkt-filter-mode=perfect --rxq=2 --txq=2 and the relative output: ... Interactive-mode selected Configuring Port 0 (socket -1) Fail to start port 0 (ret=-5)* Configuring Port 1 (socket -1) Fail to start port 1 (ret=-5)* Please stop the ports first Done testpmd> *ret=-5 is the result of the rte_eth_dev_start function I guess someone was able to use FDIR, at least in the testpmd application. What am I doing wrong? Best regards > From: thomas.monjalon at 6wind.com > To: fulvio.risso at polito.it > Date: Thu, 6 Feb 2014 17:47:21 +0100 > CC: dev at dpdk.org > Subject: Re: [dpdk-dev] Is Flow Director supported on the x540 chipset? > > Hi Fulvio, > > 17/01/2014 12:24, Maxime Leroy: > > On Thu, Jan 16, 2014, Fulvio Risso wrote: > > > by digging into the DPDK code it seems to me that FDIR is not supported > > > on the x540 chipset, while it is supported on 82599. > [...] > > > Is there any plan to support FDIR to the x540 chipset? > > > [...] > > I think you only need to change few lines in > > lib/librte_pmd_ixgbe/ixgbe_fdir.c: > > > > - if (hw->mac.type != ixgbe_mac_82599EB) > > + if (hw->mac.type != ixgbe_mac_82599EB || hw->mac.type != > > ixgbe_mac_X540) > > > > Let me know if you can test it and please provide a patch if it works. > > Have you tried to patch and test flow director for X540 ? > > thanks > -- > Thomas
[dpdk-dev] Is Flow Director supported on the x540 chipset?
Hi Bruce, your answer was really helpful. The application didn't work due to this line "if (hw->mac.type != ixgbe_mac_82599EB || hw->mac.type !=ixgbe_mac_X540)". I changed the || whit a && and now the application (with the FDIR mode active) runs on both X540 and 82599. Now I'm testing if the FDIR really works properly also on the X540 ; if it works, I will provide a patch. Best Regards, Mauro > From: bruce.richardson at intel.com > To: mauroannarumma at hotmail.it; dev at dpdk.org > Subject: RE: [dpdk-dev] Is Flow Director supported on the x540 chipset? > Date: Thu, 13 Feb 2014 10:28:37 + > > Hi, > > can you please give a few more details about your setup? What version of the > Intel DPDK are you using? I tried using the command you give below on my > system with 82599-based NICs and testpmd starts up without any issues. > > Here's the (clipped for brevity) output that I get: > > $ sudo ./testpmd -c 0x0f -n 2 -m 512 -- -i --portmask=0x3 --nb-cores=2 > --pkt-filter-mode=perfect --rxq=2 --txq=2 > EAL: No free hugepages reported in hugepages-2048kB > EAL: Detected lcore 0 as core 0 on socket 0 > EAL: Detected lcore 1 as core 1 on socket 0 > ... ... > Interactive-mode selected > previous number of forwarding ports 4 - changed to number of configured ports > 2 > Configuring Port 0 (socket 1) > Configuring Port 1 (socket 1) > Configuring Port 2 (socket 1) > Configuring Port 3 (socket 1) > Checking link statuses... > Port 0 Link Up - speed 1 Mbps - full-duplex > Port 1 Link Up - speed 1 Mbps - full-duplex > Port 2 Link Up - speed 1 Mbps - full-duplex > Port 3 Link Up - speed 1 Mbps - full-duplex > Done > testpmd> > > > Perhaps you could also try turning on some of the IXGBE debug options in your > compile time config e.g. defconfig_x86_64-default-linuxapp-gcc. Setting > "CONFIG_RTE_LIBRTE_IXGBE_DEBUG_INIT" and > "CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER" to "y" might provide some useful > output. > > Regards, > /Bruce > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mauro > > Annarumma > > Sent: Thursday, February 13, 2014 9:45 AM > > To: dev at dpdk.org > > Subject: Re: [dpdk-dev] Is Flow Director supported on the x540 chipset? > > > > Hi, > > I'm trying to use Flow Director. Initially I used a X540 chipset and I was > > not > > able to make it work; I thought it was a compatibility problem with the > > controller. Maxime suggested to change some lines in the ixgbe_fdir.c file, > > I > > changed these lines but it > > did not give the expected results; > >At this point I was sure that the problem was the incompatibility between > > the DPDK and the X540 chipset therefore I retrived a NIC whit a 82599 > > chipset and I repeated my attempts, unfortunately I got the some > > problems. > > > > In order to be more clear I explain my attempts: > > I try to run the test-pmd app with the command-line option > > "--pkt-filter-mode=perfect", the app doesn't start (the > > rte_eth_dev_start > > function return an error) otherwise without the --pkt-filter-mode > > command-line option the application run > > normally. > > > > This is the command line I use to start the program: > > > > frog at frog:~/dpdk-1.5.2r1/app/test-pmd$ > > sudo ./testpmd -c 0x0f -n 2 -m 512 -- -i --portmask=0x3 --nb-cores=2 --pkt- > > filter-mode=perfect --rxq=2 --txq=2 > > > > > > and the relative output: > > > > ... > > Interactive-mode selected > > Configuring Port 0 (socket -1) > > Fail to start port 0 (ret=-5)* > > Configuring Port 1 (socket -1) > > Fail to start port 1 (ret=-5)* > > Please stop the ports first > > Done > > testpmd> > > > > *ret=-5 is the result of the rte_eth_dev_start function > > > > I guess someone was able to use FDIR, at least in the testpmd application. > > What am I doing wrong? > > Best regards > > > > > From: thomas.monjalon at 6wind.com > > > To: fulvio.risso at polito.it > > > Date: Thu, 6 Feb 2014 17:47:21 +0100 > > > CC: dev at dpdk.org > > > Subject: Re: [dpdk-dev] Is Flow Director supported on the x540 chipset? > > > > > > Hi Fulvio, > > > > > > 17/01/2014 12:24, Maxime Leroy: > > > > On Thu, Jan 16, 2014, Fulvio Risso wrote: > > > > > by digging into the DPDK code it seems to me that FDIR is not > > supported > > > > > on the x540 chipset, while it is supported on 82599. > > > [...] > > > > > Is there any plan to support FDIR to the x540 chipset? > > > > > > > [...] > > > > I think you only need to change few lines in > > > > lib/librte_pmd_ixgbe/ixgbe_fdir.c: > > > > > > > > - if (hw->mac.type != ixgbe_mac_82599EB) > > > > + if (hw->mac.type != ixgbe_mac_82599EB || hw->mac.type != > > > > ixgbe_mac_X540) > > > > > > > > Let me know if you can test it and please provide a patch if it works. > > > > > > Have you tried to patch and test flow director for X540 ? > > > > > > thanks > > > -- > > > Thomas > >
[dpdk-dev] Question on DPDK multi-process support
Hi, I have some doubts on the DPDK multi-process support: 1) According to the Programmers Guide (pag. 109 - 20.3 Multi-process Limitations), one of the multi-process limitations is: "All Intel? DPDK processes running as a single application and using shared memory must have distinct coremask arguments. It is not possible to have a primary and secondary instance, or two secondary instances, using any of the same logical cores. Attempting to do so can cause corruption of memory pool caches, among other issues." Does it mean that I can run a number of DPDK processes at most equal to the number of my CPU logical cores? In the case I run 2 mono-lcore DPDK processes with the same coremask, what are the possible issues? 2) Can a secondary process use the rte_eth_rx_burst over a queue of a NIC port configured in the primary process? Regards, Mauro
[dpdk-dev] Question on DPDK multi-process support
Hi Bruce, just for dispel any doubt: if there is one primary process and N secondary processes, and each process uses only one logical core (they have a coremask equal to 0x01, 0x02, 0x04, ), I can run at the same time at most "my CPU logical cores - 1" secondary processes. Is it right? Is it true also if I disable the mempool per-core cache? Thanks for your help, regards. Mauro > From: bruce.richardson at intel.com > To: mauroannarumma at hotmail.it; dev at dpdk.org > Subject: RE: [dpdk-dev] Question on DPDK multi-process support > Date: Mon, 17 Feb 2014 16:44:55 + > > > Hi, > > I have some doubts on the DPDK multi-process support: > > > > 1) According to the Programmers Guide (pag. 109 - 20.3 Multi-process > > Limitations), one of the multi-process limitations is: > > > > "All Intel(r) DPDK processes running as a single application and using > > shared > > memory must have distinct coremask arguments. It is not possible to have > > a primary and secondary instance, or two secondary instances, using any of > > the same logical cores. Attempting to do so can cause corruption of > > memory pool caches, among other issues." > > > > Does it mean that I can run a number of DPDK processes at most equal to > > the number of my CPU logical cores? In the case I run 2 mono-lcore DPDK > > processes with the same coremask, what are the possible issues? > > > The potential issues are caused by a dependence on the lcore_id internally by > Intel DPDK data structures, especially mempools. If two processes use the > same lcore they will have the same lcore_id value, and will try and access > the same mempool cache which is not thread-safe. This will cause mempool > corruption. > NOTE: this applies only to co-operating processes, i.e. those run as primary > and secondary processes. There are no mempool issues with running completely > independent Intel DPDK processes on the same cores, i.e. processes run using > different "--file-prefix=" parameters, since those do not share any memory > and data structures. > > > > > 2) Can a secondary process use the rte_eth_rx_burst over a queue of a NIC > > port configured in the primary process? > > > Yes. NIC ports and their data structures are shared between co-operating > processes. Multiple processes doing RX on the same port is shown in the > "examples/multi_process/symmetric_mp" example application.
