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
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
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
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
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
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
23 matches
Mail list logo
