memif thread race condition on memif.disconnect()

Hello, We have run into a timing issue between threads when using the memif interface type and need some guidance. Our application has a DPDK based process operating (among other things) a memif server interface. The problem is exposed when this memif interface receives a memif.disconnect mess

e1000 forced 1G support?

Hello, This is in regards to the DPDK E1000 driver used for the i350 [8086:1521] NIC. I am looking to see if we can get forced speed == 1000Mb (1Gb) support working on this NIC. The current DPDK driver does not appear to have support for forcing the NIC to 1G (1000M) speed. It only supports set

RE: [**EXTERNAL**] Re: e1000 forced 1G support?

:45 AM To: Morten Brørup Cc: Bly, Mike ; dev@dpdk.org Subject: [**EXTERNAL**] Re: e1000 forced 1G support? On Fri, 11 Feb 2022 09:57:31 +0100 Morten Brørup wrote: > > From: Bly, Mike [mailto:m...@ciena.com] > > Sent: Friday, 11 February 2022 02.30 > > > > Hello, > >

IXGBE LSC IRQ issue

Hello, We recently ran into an issue with DPDK 20.11 for the IXGBE driver operating in 10G BASE-T mode. We have been able to replicate this behavior using dpdk-testpmd and do not see any recent/pertinent updates, so we are hopeful someone may be able to advise based on the information provided

[dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.

@gmail.com] Sent: Monday, August 17, 2015 11:06 AM To: Yeddula, Avinash Cc: Singh, Jasvinder; Richardson, Bruce; dev at dpdk.org; Bly, Mike Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table. Hi Avinash, I think, you can use the same table by just updating the packet meta data based

Re: [dpdk-dev] 17.05 --> 17.11, minimum hash table key size

ip_pipeline example? -MikeB -Original Message- From: Dumitrescu, Cristian Sent: Friday, June 29, 2018 4:18 AM To: Yeddula, Avinash ; dev@dpdk.org; dev ; us...@dpdk.org Cc: Bly, Mike Subject: [**EXTERNAL**] RE: 17.05 --> 17.11, minimum hash table key size > -Original M

[dpdk-dev] 17.05 --> 17.11, minimum hash table key size

Hello, We are in process of migrating our design from DPDK 17.05 to 17.11 and we ran into a small problem. Within our design, we have some hash tables with 4-byte keys. While going through the changes done in 17.11, we have found there was an added key_size check, which now requires key_size >=

[dpdk-dev] migration from 17.05 to 17.11, testpmd not able to bring up ports for virtio instance running inside a VM

Does anyone have some suggestions on where to start with this ? When we run this using DPDK 17.05, the ports come up fine for our design and testpmd. However, with 17.11, the ports to not come up and I end up with undefined rx_pkt_burst/tx_pkt_burst functions as shown here: (gdb) p rte_eth_dev

[dpdk-dev] dpdk-devbind --status and PCI-PT

Hello, I am looking to know if folks were aware that running "dpdk-debind -status" on a host displays both NICs in host space as well as those "owned" by a VM via PCI-PT where that VM is internally running a DPDK enabled application. Per below there is no discernable difference indicated as to

[dpdk-dev] ACL priority field

Hello, Can someone clarify what I am interpreting as a documentation conflict regarding the "priority" field for rte_table_acl_rule_add_params? Below documentation says "highest priority wins", but the header file comment says 0 is highest priority. Based on my testing with conflicting entries

Re: [dpdk-dev] ACL priority field

Konstantin, Ah, I see now. Yes, we are using rte_table_acl. Is there a reason these two differ in precedence selection? Regards, Mike Hi, > > Hello, > > Can someone clarify what I am interpreting as a documentation conflict > regarding the "priority" field

[dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs()

Hello, We are chasing an interesting NIC transmit issue where after some period of time with normal operation the NIC enters a state where it refuses to transmit frames from our DPDK application via rte_eth_tx_burst(). All indications are the port is up and otherwise operational and is still re

Re: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs()

y 23, 2019 9:03 AM To: Bly, Mike ; 'dev@dpdk.org' Subject: [**EXTERNAL**] RE: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs() > > Hello, > > We are chasing an interesting NIC transmit issue where after some > period of time with norma

Re: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs()

ces, so we are a bit hesitant to blindly enforce this at 60 bytes (min ETH minus CRC). -Mike -Original Message- From: Bly, Mike Sent: Tuesday, July 23, 2019 10:08 AM To: Ananyev, Konstantin ; 'dev@dpdk.org' Subject: RE: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_

Re: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs()

capable of doing. We will continue looking and update when we have more to share. -Mike -Original Message- From: Ananyev, Konstantin Sent: Wednesday, July 24, 2019 12:53 AM To: Bly, Mike ; 'dev@dpdk.org' Cc: Zhang, Qi Z ; Lu, Wenzhuo Subject: [**EXTERNAL**] RE: [dpdk

Re: [dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread

Has anyone created a dev-ticket to run this discussion to ground? I see below thread went stale in 2016... Is there a "better approach" to integrating rte_eal_intr_exit() support/concepts into our applications? -Mike From: "Liang, Cunming" To: Thomas Monjalon Cc: Matthew Hall , "dev@