On 17-01-11 07:47 PM, Chen, Jing D wrote:
> Hi, Vincent,
>
>> -Original Message-
>> From: Vincent JARDIN [mailto:vincent.jar...@6wind.com]
>> Sent: Tuesday, January 10, 2017 9:30 PM
>> To: Scott Daniels ; dev@dpdk.org
>> Cc: kaust...@research.att.com; az5...@att.com; Chen, Jing D
>>
>> Su
On 17-01-11 06:51 AM, JOSHI, KAUSTUBH (KAUSTUBH) wrote:
> Also, the kernel drivers have no concept of passing VF messages to upstream
> "decision making” (or policy enforcement) software like VFd.
>
> On Jan 11, 2017, at 9:49 AM, Kaustubh Joshi
> mailto:kaust...@research.att.com>> wrote:
>
> W
On 16-12-15 09:16 AM, Stephen Hemminger wrote:
> On Thu, 15 Dec 2016 11:53:59 +
> Ferruh Yigit wrote:
>
>> Hi Stephen,
>>
>> <...>
>>
>>>
>>> Which raises a couple of questions:
>>> 1. Why is DPDK still keeping KNI support for Intel specific ethtool
>>> functionality.
>>> This always br
[...]
>>> Well, it should be easier to answer if you have a specific use-case in mind
>>> you would like to support but that cannot be expressed with the API as
>>> defined in [1], in which case please share it with the community.
>>
>> A use-case would be implementing OvS DPIF flow offload using
On 01/09/2018 06:32 AM, Bruce Richardson wrote:
> This patch adds an AVX2 vectorized path to the i40e driver, based on the
> existing SSE4.2 version. Using AVX2 instructions gives better performance
> than the SSE version, though the percentage increase depends on the exact
> settings used. For exa
On 16-07-21 12:20 PM, Adrien Mazarguil wrote:
> Hi Jerin,
>
> Sorry, looks like I missed your reply. Please see below.
>
Hi Adrian,
Sorry for a bit delay but a few comments that may be worth considering.
To start with completely agree on the general problem statement and the
nice summary of al
On 16-07-25 04:32 AM, Rahul Lakkireddy wrote:
> Hi Adrien,
>
> On Thursday, July 07/21/16, 2016 at 19:07:38 +0200, Adrien Mazarguil wrote:
>> Hi Rahul,
>>
>> Please see below.
>>
>> On Thu, Jul 21, 2016 at 01:43:37PM +0530, Rahul Lakkireddy wrote:
>>> Hi Adrien,
>>>
>>> The proposal looks very goo
On 16-07-23 02:10 PM, John Fastabend wrote:
> On 16-07-21 12:20 PM, Adrien Mazarguil wrote:
>> Hi Jerin,
>>
>> Sorry, looks like I missed your reply. Please see below.
>>
>
> Hi Adrian,
>
> Sorry for a bit delay but a few comments that may be worth con
[...]
Considering that allowed pattern/actions combinations cannot be known in
advance and would result in an unpractically large number of capabilities
to
expose, a method is provided to validate a given rule from the current
device configuration state without actually a
[...]
>> The proposal looks very good. It satisfies most of the features
>> supported by Chelsio NICs. We are looking for suggestions on exposing
>> more additional features supported by Chelsio NICs via this API.
>>
>> Chelsio NICs have two regions in which filters can be pl
[...]
>> I'm not sure I understand 'bit granularity' here. I would say we have
>> devices now that have rather strange restrictions due to hardware
>> implementation. Going forward we should get better hardware and a lot
>> of this will go away in my view. Yes this is a long term view and
>> doesn
On 16-08-04 06:24 AM, Adrien Mazarguil wrote:
> On Wed, Aug 03, 2016 at 12:11:56PM -0700, John Fastabend wrote:
>> [...]
>>
>>>>>>>> The proposal looks very good. It satisfies most of the features
>>>>>>>> supported by Chelsio
On 16-08-10 04:02 AM, Adrien Mazarguil wrote:
> On Tue, Aug 09, 2016 at 02:24:26PM -0700, John Fastabend wrote:
> [...]
>>> Just an idea, could some kind of meta pattern items specifying time
>>> constraints for a rule address this issue? Say, how long (cycles/ms) the P
On 16-08-10 06:37 AM, Adrien Mazarguil wrote:
> On Tue, Aug 09, 2016 at 02:47:44PM -0700, John Fastabend wrote:
>> On 16-08-04 06:24 AM, Adrien Mazarguil wrote:
>>> On Wed, Aug 03, 2016 at 12:11:56PM -0700, John Fastabend wrote:
> [...]
>>>> The problem is k
On 16-08-19 12:32 PM, Adrien Mazarguil wrote:
> This new API supersedes all the legacy filter types described in
> rte_eth_ctrl.h. It is slightly higher level and as a result relies more on
> PMDs to process and validate flow rules.
>
> It has the following benefits:
>
> - A unified API is easier
On 16-08-19 12:32 PM, Adrien Mazarguil wrote:
> Hi All,
>
> Thanks to many for the positive and constructive feedback I've received so
> far. Here is the updated specification (v0.7) at last.
>
> I've attempted to address as many comments as possible but could not
> process them all just yet. A n
16 matches
Mail list logo
