[dpdk-dev] [PATCH] ring: fix minor memory free issue
2015-11-06 17:28, John McNamara:
> Fix minor memory free issue in error clean-up.
>
> Reported-by Coverity (CID 119258)
>
> Signed-off-by: John McNamara
Fixes: 651c505af862 ("ring: enhance device setup from rings")
Applied, thanks
[dpdk-dev] [PATCH 3/5] bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option
>2015-10-23 22:28, Harish Patil: >> >2015-09-11 17:42, Rasesh Mody: >> >> From: Harish Patil >> >> --- a/config/common_linuxapp >> >> +++ b/config/common_linuxapp >> >> @@ -220,6 +220,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n >> >> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n >> >> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n >> >> CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n >> >> +CONFIG_RTE_LIBRTE_BNX2X_REG_ACCESS=n >> > >> >Why do you need this option? >> >> Currently logging of register accesses is using (wrongly) the generic >> driver debug option of PMD_DRV_LOG (which gets enabled if >> CONFIG_RTE_LIBRTE_BNX2X_DEBUG=y). >> This floods the console due to excessive printing of register >> reads/writes. So creating a new debug option in order to capture only >>the >> register read/writes (if required) and also does not interfere with the >> informational/user-level debug. > >You mean there is not enough log levels? > >#define RTE_LOG_EMERG1U /**< System is unusable. */ >#define RTE_LOG_ALERT2U /**< Action must be taken immediately. */ >#define RTE_LOG_CRIT 3U /**< Critical conditions. */ >#define RTE_LOG_ERR 4U /**< Error conditions. */ >#define RTE_LOG_WARNING 5U /**< Warning conditions. */ >#define RTE_LOG_NOTICE 6U /**< Normal but significant condition. */ >#define RTE_LOG_INFO 7U /**< Informational.*/ >#define RTE_LOG_DEBUG8U /**< Debug-level messages. */ > >Either other "debug" logs can be put as INFO level, or >you need a level 9 for verbose debug. >But I don't really understand what is the problem of a verbose debug. > >It is not critical for the acceptance of this patch. Just wanted to >discuss >it as we have many config options to tune the debug. > >Please, at least, use the DEBUG word in the option name as done for >CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX. > Currently PMD_DRV_LOG(DEBUG,..) is used all over the places and converting that into INFO/NOTICE levels results in lot of changes. Even if we convert other debug logs as INFO level logs, since level 8 is the default debug level, the user would have to edit config file to prevent flooding of the messages on the console. So I guess adding a debug option without needing additional level would suffice for now. I shall rename it as CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC and include all periodic events like statistics, register R/Ws etc under this debug. Thanks, Harish This message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
[dpdk-dev] PMD/l3fwd issue
> > >> -Original Message- >> From: Harish Patil [mailto:harish.patil at qlogic.com] >> Sent: Friday, September 04, 2015 2:08 PM >> To: Ananyev, Konstantin; dev at dpdk.org >> Cc: Ameen Rahman >> Subject: Re: PMD/l3fwd issue >> >> Hi Konstantin, >> >> >Hi Patil, >> > >> >> -Original Message- >> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Harish Patil >> >> Sent: Thursday, September 03, 2015 4:53 PM >> >> To: dev at dpdk.org >> >> Subject: [dpdk-dev] PMD/l3fwd issue >> >> >> >> Hello, >> >> Have a question regarding l3fwd application. The l3fwd application >> >>expects >> >> the poll mode driver to return packets whose L2 header is 16-byte >> >>aligned. >> > >> >Yep, and as I remember, by default PMD returns ti the upper layer mbufs >> >with data offsets >> >aligned to cahce line size (64B). >> >Unless you'll change RTE_PKTMBUF_HEADROOM config parameter. >> > >> >> Otherwise, it results in a crash. This is due to use of >>_mm_load_si128() >> >> and _mm_store_si128() intrinsics which expects the address to be >>16-byte >> >> aligned. However, most of the real protocol stack expects packets >>such >> >> that its IP header be aligned on a 16-byte boundary (not L2). Its not >> >>just >> >> for IP but any L3 for that matter. That?s way we usually see >> >> skb_reserve(skb, NET_IP_ALIGN) calls in linux drivers. >> > >> >Well, l3fwd is just an example application to demonstrate usage of DPDK >> >API >> >And max performance it could get for that type of workload. >> >No-one forces you to use aligned load/store in your own application. >> >> Yes, I agree if its our private application. But l3fwd being widely used >> as a benchmarking/testing tool and they may ran into this issue. >> > >If someone would try to run it with RTE_PKTMBUF_HEADROOM non-aligned on >16B, then probably yes. > >> > >> >> >> >> So I?m looking for suggestions here, whether l3wd application or poll >> >>mode >> >> driver should be changed to fix that? What is the right thing to do? >> >> Can a check be added in l3fwd to use _mm_loadu_si128/_mm_storeu_si128 >> >> instructions instead of mm_load_si128/_mm_store_si128 if address is >> >>found >> >> not be 16B aligned? >> > >> >I'd personally just change l3fwd to use to use >> >_mm_loadu_si128/_mm_storeu_si128 unconditionally. >> >As by default address is 16B aligned anyway, I think that using MOVDQU >> >instead of MOVDQA here >> >shouldn't make that big difference. >> >But off course testing need to be done to make sure there is no >> >performance drop with that change. >> >> I too would just change l3fwd application so that all poll mode drivers >> would just work. Are you proposing that we upstream l3fwd change if we >> don?t see performance drop? > >Yep, I'd suggest to verify there is no performance difference and submit >a patch. >From our side we can do some extra performance testing too. >Thanks >Konstantin Hi Konstantin, As you suggested, I have submitted the patch. Thanks, Harish > >> >> >Konstantin >> > >> >> >> >> Thanks, >> >> Harish >> >> >> >> >> >> >> >> >> >> >> >> This message and any attached documents contain information from the >> >>sending company or its parent company(s), subsidiaries, >> >> divisions or branch offices that may be confidential. If you are not >> >>the intended recipient, you may not read, copy, distribute, or use >> >> this information. If you have received this transmission in error, >> >>please notify the sender immediately by reply e-mail and then delete >> >> this message. >> > >> >> >> >> >> >> This message and any attached documents contain information from the >>sending company or its parent company(s), subsidiaries, >> divisions or branch offices that may be confidential. If you are not >>the intended recipient, you may not read, copy, distribute, or use >> this information. If you have received this transmission in error, >>please notify the sender immediately by reply e-mail and then delete >> this message. > This message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
[dpdk-dev] DPDK2.1 VF and NIC X552 PF - ixgbe SRIOV works?
Hi,? Wenzhuo: The Dev ID is 15a8 (device_id = 5544, vendor_id = 32902)About SR-IOV between this NIC and DPDK2.1? Or when DPDK will support SR-IOV for this NIC? Thanks. On Tuesday, November 3, 2015 6:13 PM, "Lu, Wenzhuo" wrote: Hi Zhongliang, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhongliang Shu > Sent: Wednesday, November 4, 2015 7:07 AM > To: dev at dpdk.org > Subject: [dpdk-dev] DPDK2.1 VF and NIC X552 PF - ixgbe SRIOV works? > > Hi, Guys: > I have developed a VM to use SRIOV VF of DPDK2.1 libraryand its PF NIC is > interl X552 NIC. The VM is deployed on KVM on Linux box. > NIC Inforoot at localhost:~# modinfo ixgbe > filename:?? /lib/modules/3.14.49-rt46- > WR7.0.0.5_ovp/kernel/drivers/juniper/x552-nic/ixgbe.ko > version:??? 4.2.0.4.1-unreleased > license:??? GPL > description:??? Intel(R) 10 Gigabit PCI Express Network Driver Linux Box > InfoLinux localhost 3.14.49-rt46-WR7.0.0.5_ovp #1 SMP PREEMPT RT Mon Oct > 26 12:24:18 PDT 2015 x86_64 GNU/Linux When the VM start, and its correct > corresponding MAC is pushed into PF. > 4: sxe0: mtu > 1500 qdisc mq master eth1br state UP mode DEFAULT group default qlen > 1000 > ??? link/ether 88:a2:5e:09:bd:c1 brd ff:ff:ff:ff:ff:ff > ??? vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto > ??? vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto > ??? vf 2 MAC 52:54:00:ba:fa:f7, spoof checking on, link-state auto > ??? vf 3 MAC 52:54:00:ee:e6:0d, spoof checking on, link-state auto Linux Host > dmesg:root at localhost:/lib# dmesg [62995.451770] pci-stub :03:10.4: > claimed by stub [62995.465783] ixgbe :03:00.0: setting MAC > 52:54:00:ba:fa:f7 on VF 2 [62995.465785] ixgbe :03:00.0: Reload the VF > driver to make this change effective. > [62995.520671] device vnet4 entered promiscuous mode [62995.520900] > eth0br: port 4(vnet4) entered forwarding state [62995.520911] eth0br: port > 4(vnet4) entered forwarding state [62995.71] pci-stub :03:10.4: > enabling device ( -> 0002) [62998.148072] pci-stub :03:10.4: kvm > assign device [63010.548139] eth0br: port 4(vnet4) entered forwarding state > [63050.387806] pci-stub :03:10.4: irq 97 for MSI/MSI-X [63050.399811] > pci-stub :03:10.4: irq 97 for MSI/MSI-X [63289.573419] ixgbe :03:00.0 > sxe0: VF Reset msg received from vf 2 [63290.033229] ixgbe :03:00.0 sxe0: > VF Reset msg received from vf 2 [63953.063867] ixgbe :03:00.0: Malicious > event on VF 2 tx:10 rx:0 Several questions about the log msgs > 1): its keep to see the log msgs: [63289.573419] ixgbe :03:00.0 sxe0: > VF > Reset msg received from vf 2 > [63290.033229] ixgbe :03:00.0 sxe0: VF Reset msg received from vf > 2??? what reason cause these msg? > 2): When try ping from the VM,?? it fails and there has msg: > ?? ?? [63953.063867] ixgbe :03:00.0: Malicious event on VF 2 tx:10 > rx:0 > ??? what reason causes this msg? > 3): Does DPDK2.1 VF and X552 PF is tested and supported? > By the way, the SRIOV of this VM work fine for X550 NIC and? 82580 NIC, > Thanks. I'm afraid x552 is not supported yet. Would you like to give me the device id to confirm that?
[dpdk-dev] [PATCH 3/5] bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option
> >Either other "debug" logs can be put as INFO level, or > >you need a level 9 for verbose debug. > >But I don't really understand what is the problem of a verbose debug. > > > >It is not critical for the acceptance of this patch. Just wanted to > >discuss > >it as we have many config options to tune the debug. > > > >Please, at least, use the DEBUG word in the option name as done for > >CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX. > > > > Currently PMD_DRV_LOG(DEBUG,..) is used all over the places and converting > that into INFO/NOTICE levels results in lot of changes. Having a lot of changes to do is not a good argument. But that's an argument to reduce the size of the bnx2x driver. And more generally, this driver would deserve some big changes. > Even if we convert other debug logs as INFO level logs, since level 8 is > the default debug level, the user would have to edit config file to > prevent flooding of the messages on the console. The user *should* change the log evel in most cases. Or we could raise the default level to INFO. And users of packaged DPDK may already have a different configuration from the distribution. > So I guess adding a debug > option without needing additional level would suffice for now. I shall > rename it as CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC and include all > periodic events like statistics, register R/Ws etc under this debug. Yes it could work. But it would be nice to have a consistent log management across drivers.
