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
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
: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,
> >
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
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@
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
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
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
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
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_
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
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
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
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 >=
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
@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
16 matches
Mail list logo