On Mon, Feb 4, 2019 at 12:19 PM Rami Rosen wrote:
> Hi, Alejandro,
>
> Thanks for you quick response.
>
> >When SRIOV is used by VMs, the slow path will always be faster (and
> >with lower latency) with DPDK.
>
> Yes, I am referring primarily to the SRIOV case in my question, when
> assigning PCI
Hi, Alejandro,
Thanks for you quick response.
>When SRIOV is used by VMs, the slow path will always be faster (and
>with lower latency) with DPDK.
Yes, I am referring primarily to the SRIOV case in my question, when
assigning PCI VF to a VM (most likely QEMU VM)
Can you please explain what you m
On Mon, Feb 4, 2019 at 10:44 AM Rami Rosen wrote:
> Hi Alejandro,
>
> >Your concern is related to this thread
>
> Thanks for your reply, I was aware of this thread.
>
OK
> Still, I am not sure, in current kernels and currently available Ethernet
> DPDK PMDs about the answer to my queries (I don
Hi Alejandro,
>Your concern is related to this thread
Thanks for your reply, I was aware of this thread.
Still, I am not sure, in current kernels and currently available Ethernet
DPDK PMDs about the answer to my queries (I don't think this mail thread
gives info about it), like about what are th
Hi Rami,
Your concern is related to this thread:
http://mails.dpdk.org/archives/dev/2019-January/123466.html
I'm working on solving the problem when PF needs to be bound to VFIO. My
proposal is to use mediated devices.
Although it is not strictly necessary to rely on current kernel WiP about
VFI
Hello all,
Now that DPDK 19.02 was released three days ago (on time!!), hopefully
there will be time
for people to answer the following question:
According to the "DPDK Getting Started Guide",
"If UEFI secure boot is enabled, the Linux kernel may disallow the use of
UIO on the system.
T
Hi all,
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Thursday, December 7, 2017 9:02 AM
> To: Ananyev, Konstantin
> Cc: Ilya Matveychikov ; dev@dpdk.org; Hu, Jiayu
>
> Subject: Re: [dpdk-dev] A question about GRO nei
> On Dec 7, 2017, at 5:01 AM, Stephen Hemminger
> wrote:
>
> Ok, went RFC hunting and the relevant one seems to be RFC 6864.
> It mandates unique id's for each datagram so TCP does send them.
>
>
Thanks for mention such the RFC, never heard about it.
dev@dpdk.org; Hu, Jiayu
> > Subject: Re: [dpdk-dev] A question about GRO neighbor packet matching
> >
> > On Wed, 6 Dec 2017 22:38:12 +0400
> > Ilya Matveychikov wrote:
> >
> > > > On Dec 6, 2017, at 10:12 PM, Stephen Hemminger
> > > &
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Wednesday, December 6, 2017 11:16 PM
> To: Ilya Matveychikov
> Cc: dev@dpdk.org; Hu, Jiayu
> Subject: Re: [dpdk-dev] A question about GRO neighbor packet matching
On Wed, 6 Dec 2017 22:38:12 +0400
Ilya Matveychikov wrote:
> > On Dec 6, 2017, at 10:12 PM, Stephen Hemminger
> > wrote:
> >
> > On Wed, 6 Dec 2017 18:02:21 +0400
> > Ilya Matveychikov wrote:
> >
> >> Hello all,
> >>
> >>
> >> My question is about neighbor packet matching algorithm for T
> On Dec 6, 2017, at 10:12 PM, Stephen Hemminger
> wrote:
>
> On Wed, 6 Dec 2017 18:02:21 +0400
> Ilya Matveychikov wrote:
>
>> Hello all,
>>
>>
>> My question is about neighbor packet matching algorithm for TCP. Is it
>> correct to expect that IP packets should have continuous ID enumerat
On Wed, 6 Dec 2017 18:02:21 +0400
Ilya Matveychikov wrote:
> Hello all,
>
>
> My question is about neighbor packet matching algorithm for TCP. Is it
> correct to expect that IP packets should have continuous ID enumeration
> (i.e. iph-next.id = iph-prev.id + 1)?
No.
> ~~~
> lib/librte_gro/gr
Hello all,
My question is about neighbor packet matching algorithm for TCP. Is it
correct to expect that IP packets should have continuous ID enumeration
(i.e. iph-next.id = iph-prev.id + 1)?
~~~
lib/librte_gro/gro_tcp4.c:check_seq_option()
...
/* check if the two packets are nei
PM
To: Wu, Xiaoban
Cc: us...@dpdk.org; dev@dpdk.org
Subject: Re: [dpdk-dev] A question about the possible race condition in the
l3fwd example?
On Tue, 28 Nov 2017 02:22:57 +
"Wu, Xiaoban" wrote:
> Dear All,
>
>
> I am studying the source code of the l3fwd example.
On Tue, 28 Nov 2017 02:22:57 +
"Wu, Xiaoban" wrote:
> Dear All,
>
>
> I am studying the source code of the l3fwd example. I am confused about a
> possible race condition in the l3fwd_lpm_simple_forward().
>
>
> In this function it calls send_single_packet(), which executes the following
Dear All,
I am studying the source code of the l3fwd example. I am confused about a
possible race condition in the l3fwd_lpm_simple_forward().
In this function it calls send_single_packet(), which executes the following
code,
len = qconf->tx_mbufs[port].len;
qconf->tx_mbufs[port].m_t
On 11/13/2017 10:33 PM, Ilya Matveychikov wrote:
On Nov 13, 2017, at 9:15 PM, Adrien Mazarguil
wrote:
On Mon, Nov 13, 2017 at 02:56:23PM +0400, Ilya Matveychikov wrote:
On Nov 13, 2017, at 2:39 PM, Adrien Mazarguil
wrote:
On Sat, Nov 11, 2017 at 09:18:45PM +0400, Ilya Matveychikov wrote:
> On Nov 13, 2017, at 9:15 PM, Adrien Mazarguil
> wrote:
>
> On Mon, Nov 13, 2017 at 02:56:23PM +0400, Ilya Matveychikov wrote:
>>
>>> On Nov 13, 2017, at 2:39 PM, Adrien Mazarguil
>>> wrote:
>>>
>>> On Sat, Nov 11, 2017 at 09:18:45PM +0400, Ilya Matveychikov wrote:
Folks,
A
On Mon, Nov 13, 2017 at 02:56:23PM +0400, Ilya Matveychikov wrote:
>
> > On Nov 13, 2017, at 2:39 PM, Adrien Mazarguil
> > wrote:
> >
> > On Sat, Nov 11, 2017 at 09:18:45PM +0400, Ilya Matveychikov wrote:
> >> Folks,
> >>
> >> Are you serious with it:
> >>
> >> typedef uint16_t (*eth_rx_burst
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Monday, November 13, 2017 10:39 AM
> To: Ilya Matveychikov
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] A question about (poor) rte_ethdev internal rx/tx
> callbac
> On Nov 13, 2017, at 2:39 PM, Adrien Mazarguil
> wrote:
>
> On Sat, Nov 11, 2017 at 09:18:45PM +0400, Ilya Matveychikov wrote:
>> Folks,
>>
>> Are you serious with it:
>>
>> typedef uint16_t (*eth_rx_burst_t)(void *rxq,
>> struct rte_mbuf **rx_pkts,
>>
On Sat, Nov 11, 2017 at 09:18:45PM +0400, Ilya Matveychikov wrote:
> Folks,
>
> Are you serious with it:
>
> typedef uint16_t (*eth_rx_burst_t)(void *rxq,
> struct rte_mbuf **rx_pkts,
> uint16_t nb_pkts);
> typedef uint16_t (*eth_t
11/11/2017 18:18, Ilya Matveychikov:
> Folks,
>
> Are you serious with it:
No, DPDK is not serious, just a hobby for few crazy folks ;)
Usually, we have fun discussions when someone explains clearly an issue.
Please do not hesitate to bring your lights,
we will check how seriously we can improve
Folks,
Are you serious with it:
typedef uint16_t (*eth_rx_burst_t)(void *rxq,
struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
typedef uint16_t (*eth_tx_burst_t)(void *txq,
struct rte_mbuf **tx_p
Dear DPDK users,
I am working on the l3fwd-acl example
http://dpdk.org/doc/guides/sample_app_ug/l3_forward_access_ctrl.html.
I just find that the macro "RTE_ETH_IS_IPV4_HDR" used on line 699 and 752 of
the main.c rejected all the normal UDP packets.
Hence, I want to know if the PMD driver i
The commit 414b202343ce8ad (bonding: fix initial link status of slave) invokes
lsc callback,
the lsc callback may be executed at same time when slave_configure() and
bond_ethdev_slave_link_status_change_monitor ()
competing for calling the lsc callback. The panic will be triggered when bond
ethd
On Fri, Jan 13, 2017 at 10:20:55AM +, wangyunjian wrote:
> In function fill_vec_buf, it will happen uint32_t cast to uint16_t, when the
> *desc_chain_len is assigned by the len.
>
> This maybe result in data truncation.
Do you have a real example?
I don't think data truncation could happen h
In function fill_vec_buf, it will happen uint32_t cast to uint16_t, when the
*desc_chain_len is assigned by the len.
This maybe result in data truncation.
static inline int __attribute__((always_inline))
fill_vec_buf(struct virtio_net *dev, struct vhost_virtqueue *vq,
Hi Kanani
Within around one year, we have implemented input set to reconfigure some
registers to select which field to be used for hash calculation.
So I think it should work quite better now with using X710 or XL710. What’s
your issue here?
Could you help to have a try and tell me the real issu
Dear all,
I am so sorry to send this question in dev mailing list. I sent this to
users' mailing list, but no one response and that list is not so active.
So, may I ask this question in this list? If it is not ok, I say sorry in
advance.
---
2014-12-12 09:59, Bruce Richardson:
> On Fri, Dec 12, 2014 at 04:07:40AM +, L?szl? Vadkerti wrote:
> > On Thu, 11 Dec, 2014, Bruce Richardson wrote:
> > > On Wed, Dec 10, 2014 at 07:16:59PM +, L?szl? Vadkerti wrote:
> > > >
> > > > On Wed, 10 Dec 2014, Bruce Richardson wrote:
> > > >
> > >
On Fri, Dec 12, 2014 at 04:07:40AM +, L?szl? Vadkerti wrote:
> On Thu, 11 Dec, 2014, Bruce Richardson wrote:
> > On Wed, Dec 10, 2014 at 07:16:59PM +, L?szl? Vadkerti wrote:
> > >
> > > On Wed, 10 Dec 2014, Bruce Richardson wrote:
> > >
> > > > On Wed, Dec 10, 2014 at 09:29:26AM -0500, Nei
On Thu, 11 Dec, 2014, Bruce Richardson wrote:
> On Wed, Dec 10, 2014 at 07:16:59PM +, L?szl? Vadkerti wrote:
> >
> > On Wed, 10 Dec 2014, Bruce Richardson wrote:
> >
> > > On Wed, Dec 10, 2014 at 09:29:26AM -0500, Neil Horman wrote:
> > >> On Wed, Dec 10, 2014 at 10:32:25AM +, Bruce Richar
On Wed, Dec 10, 2014 at 07:16:59PM +, L?szl? Vadkerti wrote:
> na ez :)
>
> On Wed, 10 Dec 2014, Bruce Richardson wrote:
>
> > On Wed, Dec 10, 2014 at 09:29:26AM -0500, Neil Horman wrote:
> >> On Wed, Dec 10, 2014 at 10:32:25AM +, Bruce Richardson wrote:
> >>> On Tue, Dec 09, 2014 at 02:1
na ez :)
On Wed, 10 Dec 2014, Bruce Richardson wrote:
> On Wed, Dec 10, 2014 at 09:29:26AM -0500, Neil Horman wrote:
>> On Wed, Dec 10, 2014 at 10:32:25AM +, Bruce Richardson wrote:
>>> On Tue, Dec 09, 2014 at 02:10:32PM -0800, Stephen Hemminger wrote:
On Tue, 9 Dec 2014 11:45:07 -0800
>
On Wed, Dec 10, 2014 at 09:29:26AM -0500, Neil Horman wrote:
> On Wed, Dec 10, 2014 at 10:32:25AM +, Bruce Richardson wrote:
> > On Tue, Dec 09, 2014 at 02:10:32PM -0800, Stephen Hemminger wrote:
> > > On Tue, 9 Dec 2014 11:45:07 -0800
> > > &rew wrote:
> > >
> > > > > Hey Folks,
> > > > >
>
On Tue, Dec 09, 2014 at 02:10:32PM -0800, Stephen Hemminger wrote:
> On Tue, 9 Dec 2014 11:45:07 -0800
> &rew wrote:
>
> > > Hey Folks,
> > >
> > > Our DPDK application deals with very large in memory data structures, and
> > > can potentially use tens or even hundreds of gigabytes of hugepage me
On Wed, Dec 10, 2014 at 10:32:25AM +, Bruce Richardson wrote:
> On Tue, Dec 09, 2014 at 02:10:32PM -0800, Stephen Hemminger wrote:
> > On Tue, 9 Dec 2014 11:45:07 -0800
> > &rew wrote:
> >
> > > > Hey Folks,
> > > >
> > > > Our DPDK application deals with very large in memory data structures,
Hi
> Hey Folks,
>
> Our DPDK application deals with very large in memory data structures, and
> can potentially use tens or even hundreds of gigabytes of hugepage
> memory.
> During the course of development, we've noticed that as the number of
> huge pages increases, the memory initialization ti
Hey Everybody,
Thanks for the feedback. Yeah, we're pretty sure that the amount of memory
we work with is atypical, and we're hitting something that isn't an issue
for most DPDK users.
To clarify, yes, we're using 1GB hugepages, and we set them up via
hugepagesz and hugepages= in our kernel's gr
On Tue, 9 Dec 2014 11:45:07 -0800
&rew wrote:
> > Hey Folks,
> >
> > Our DPDK application deals with very large in memory data structures, and
> > can potentially use tens or even hundreds of gigabytes of hugepage memory.
> > During the course of development, we've noticed that as the number of h
> Hey Folks,
>
> Our DPDK application deals with very large in memory data structures, and
> can potentially use tens or even hundreds of gigabytes of hugepage memory.
> During the course of development, we've noticed that as the number of huge
> pages increases, the memory initialization time duri
On Tue, Dec 09, 2014 at 10:33:59AM -0600, Matt Laswell wrote:
> Our DPDK application deals with very large in memory data structures, and
> can potentially use tens or even hundreds of gigabytes of hugepage memory.
What you're doing is an unusual use case and this is open source code where
nobody
Hey Folks,
Our DPDK application deals with very large in memory data structures, and
can potentially use tens or even hundreds of gigabytes of hugepage memory.
During the course of development, we've noticed that as the number of huge
pages increases, the memory initialization time during EAL init
cv
? 2013-8-20?12:37?"Bob Chen" ???
> Hi folks,
>
> Is there anyone who has researched the mechanism of DPDK ring buffer by any
> chance? I was trying to understand the multi-producer and muti-consumer
> scenario, the CAS(compare and swap) operation is not an obstacle to me, and
> from what
Hi Bob,
> do {
> prod_head = r->prod.head;
> cons_tail = r->cons.tail;
> prod_next = prod_head + n;
> success = rte_atomic32_cmpset(&r->prod.head, prod_head,
> prod_next);
>
> /*
> * Why no
Hi folks,
Is there anyone who has researched the mechanism of DPDK ring buffer by any
chance? I was trying to understand the multi-producer and muti-consumer
scenario, the CAS(compare and swap) operation is not an obstacle to me, and
from what I can tell, the method which DPDK adopts is basica
Hi folks,
Is there anyone who has researched the mechanism of DPDK ring buffer by any
chance? I was trying to understand the multi-producer and muti-consumer
scenario, the CAS(compare and swap) operation is not an obstacle to me, and
from what I can tell, the method which DPDK adopts is basica
Hello Ben,
> OK, here is the question: Why DPDK has to maintain that public prod_tail
> structure? Is it really necessary to endure a while loop here?
If you remove this wait loop, you can trigger an issue. Imagine a case
where core 0 wants to add an object in the ring: it does the CAS,
modifying
Bob
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier MATZ
Sent: Tuesday, August 20, 2013 4:22 PM
To: Bob Chen
Cc: dev
Subject: Re: [dpdk-dev] A question of DPDK ring buffer
Hello Ben,
> OK, here is the question: Why DPDK has to maintain that public
> p
hi,
I'm studing Intel DPDK recently, but have a little problem,
I know that running DPDK need network card driver - igb_uio,
but after i unload the igb and load igb_uio, the network card can't be
driven ,how could this be?
Is there something wrong with my hardware? Or I ne
52 matches
Mail list logo
