lt;alejandro.luc...@netronome.com>; Rasesh Mody
> <rasesh.m...@qlogic.com>; Jacob, Jerin <jerin.ja...@cavium.com>;
> Yuanhan Liu <yuanhan@linux.intel.com>; Yong Wang
> <yongw...@vmware.com>; Kulasek, TomaszX
> <tomaszx.kula...@intel.com>; olivier.m...@6w
On Thu, Dec 01, 2016 at 09:58:31AM +0100, Thomas Monjalon wrote:
> 2016-12-01 08:15, Adrien Mazarguil:
> > I'm perhaps a bit pessimistic mind you, but I do not think tx_prepare() will
> > remain optional for long. Sure, PMDs that do not implement it do not care,
> > I'm focusing on applications,
Hi Thomas,
On Monday, November 11/28/16, 2016 at 16:33:06 +0530, Thomas Monjalon wrote:
> We need attention of every PMD developers on this thread.
>
> Reminder of what Konstantin suggested:
> "
> - if the PMD supports TX offloads AND
> - if to be able use any of these offloads the upper layer
On 11/30/2016 6:26 PM, Thomas Monjalon wrote:
> 2016-11-30 17:42, Ananyev, Konstantin:
Please, we need a comment for each driver saying
"it is OK, we do not need any checksum preparation for TSO"
or
"yes we have to implement tx_prepare or TSO will not work in this mode"
Hi Tomasz,
On Wed, Nov 30, 2016 at 10:30:54AM +, Kulasek, TomaszX wrote:
[...]
> > > In my opinion the second approach is both faster to applications and
> > > more friendly from a usability perspective, am I missing something
> > obvious?
> >
> > I think it was not clearly explained in this
Hi Konstantin,
On Wed, Nov 30, 2016 at 10:54:50AM +, Ananyev, Konstantin wrote:
[...]
> > Something is definitely needed here, and only PMDs can provide it. I think
> > applications should not have to clear checksum fields or initialize them to
> > some magic value, same goes for any other
On Wed, Nov 30, 2016 at 07:26:36PM +0100, Thomas Monjalon wrote:
> 2016-11-30 17:42, Ananyev, Konstantin:
> > > >Please, we need a comment for each driver saying
> > > >"it is OK, we do not need any checksum preparation for TSO"
> > > >or
> > > >"yes we have to implement tx_prepare or TSO will not
2016-11-30 17:42, Ananyev, Konstantin:
> > >Please, we need a comment for each driver saying
> > >"it is OK, we do not need any checksum preparation for TSO"
> > >or
> > >"yes we have to implement tx_prepare or TSO will not work in this mode"
> > >
> >
> > qede PMD doesn?t currently support TSO
>
>
>
>Hi Harish,
>>
>>
>> >We need attention of every PMD developers on this thread.
>> >
>> >Reminder of what Konstantin suggested:
>> >"
>> >- if the PMD supports TX offloads AND
>> >- if to be able use any of these offloads the upper layer SW would have
>> >to:
>> >* modify the contents
Hi Harish,
>
>
> >We need attention of every PMD developers on this thread.
> >
> >Reminder of what Konstantin suggested:
> >"
> >- if the PMD supports TX offloads AND
> >- if to be able use any of these offloads the upper layer SW would have
> >to:
> >* modify the contents of the packet OR
>We need attention of every PMD developers on this thread.
>
>Reminder of what Konstantin suggested:
>"
>- if the PMD supports TX offloads AND
>- if to be able use any of these offloads the upper layer SW would have
>to:
>* modify the contents of the packet OR
>* obey HW specific
On Mon,
??
Nov 28, 2016 at 5:03 AM, Thomas Monjalon wrote:
> We need attention of every PMD developers on this thread.
>
> Reminder of what Konstantin suggested:
> "
> - if the PMD supports TX offloads AND
> - if to be able use any of these offloads the upper layer SW would have to:
> *
> ; Jakub Palider ; John Daley
> > (johndale) ; Adrien Mazarguil
> > ; Alejandro Lucero
> > ; Harish Patil
> > ; Rasesh Mody ; Jerin
> > Jacob ; Yuanhan Liu
> > ; Yong Wang
> > Cc: Tomasz Kulasek ;
> > konstantin.ananyev at intel.com; olivier.matz at 6w
Hi Adrien,
>
> On Mon, Nov 28, 2016 at 12:03:06PM +0100, Thomas Monjalon wrote:
> > We need attention of every PMD developers on this thread.
>
> I've been following this thread from the beginning while working on rte_flow
> and wanted to see where it was headed before replying. (I know, v11
Hi,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, November 30, 2016 09:50
> To: Adrien Mazarguil ; Kulasek, TomaszX
>
> Cc: dev at dpdk.org; Ananyev, Konstantin ;
> olivier.matz at 6wind.com
> Subject: Re: [
2016-11-30 08:40, Adrien Mazarguil:
[...]
> I understand tx_prep() automates this process, however I'm wondering why
> isn't the TX burst function doing that itself. Using nb_mtu_seg_max as an
> example, tx_prep() has an extra check in case of TSO that the TX burst
> function does not perform.
On Mon, Nov 28, 2016 at 12:03:06PM +0100, Thomas Monjalon wrote:
> We need attention of every PMD developers on this thread.
I've been following this thread from the beginning while working on rte_flow
and wanted to see where it was headed before replying. (I know, v11 was
submitted about 1 month
> ; Alejandro Lucero
> ; Harish Patil
> ; Rasesh Mody ; Jerin
> Jacob ; Yuanhan Liu
> ; Yong Wang
> Cc: Tomasz Kulasek ;
> konstantin.ananyev at intel.com; olivier.matz at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation
>
> We need attention of
We need attention of every PMD developers on this thread.
Reminder of what Konstantin suggested:
"
- if the PMD supports TX offloads AND
- if to be able use any of these offloads the upper layer SW would have to:
* modify the contents of the packet OR
* obey HW specific restrictions
then
As discussed in that thread:
http://dpdk.org/ml/archives/dev/2015-September/023603.html
Different NIC models depending on HW offload requested might impose
different requirements on packets to be TX-ed in terms of:
- Max number of fragments per packet allowed
- Max number of fragments per TSO
20 matches
Mail list logo
