On 11/21/2016 01:30 PM, Ferruh Yigit wrote:
> On 11/21/2016 8:59 AM, Thomas Monjalon wrote:
>> 2016-11-21 11:46, Andrew Rybchenko:
>>> On 11/21/2016 11:19 AM, Thomas Monjalon wrote:
> Before submitting 56 patches I'd like to double-check that checkpatch.pl
> errors (for example, because of
On 11/21/2016 11:19 AM, Thomas Monjalon wrote:
>> Before submitting 56 patches I'd like to double-check that checkpatch.pl
>> errors (for example, because of assignments in the 'if' condition,
>> parenthesis around return value) is not a show-stopper for base driver
>> import.
> You can run checkpa
On 11/21/2016 8:59 AM, Thomas Monjalon wrote:
> 2016-11-21 11:46, Andrew Rybchenko:
>> On 11/21/2016 11:19 AM, Thomas Monjalon wrote:
Before submitting 56 patches I'd like to double-check that checkpatch.pl
errors (for example, because of assignments in the 'if' condition,
parenthesi
2016-11-18 19:50, Andrew Rybchenko:
> Now we have a split of the base driver import in big feature steps. The
> base driver is split into 28 patches. Just only 1 patch exceeds 300K
> boundary (which add MCDI definitions header).
Good
> Before submitting 56 patches I'd like to double-check that
2016-11-21 11:46, Andrew Rybchenko:
> On 11/21/2016 11:19 AM, Thomas Monjalon wrote:
> >> Before submitting 56 patches I'd like to double-check that checkpatch.pl
> >> errors (for example, because of assignments in the 'if' condition,
> >> parenthesis around return value) is not a show-stopper for
On 10/28/2016 05:43 PM, Andrew Rybchenko wrote:
> On 10/28/2016 03:33 PM, Thomas Monjalon wrote:
>> 2016-10-28 13:50, Andrew Rybchenko:
>>> The only thing which comes to my mind is to split libefx import on
>>> subsystem
>>> basis (few files per subsystem). It is artificial and added files will
>>
On 10/28/2016 03:33 PM, Thomas Monjalon wrote:
> 2016-10-28 13:50, Andrew Rybchenko:
>> The only thing which comes to my mind is to split libefx import on subsystem
>> basis (few files per subsystem). It is artificial and added files will
>> be abandoned
>> until the patch which adds them into buil
On 10/28/2016 03:33 PM, Thomas Monjalon wrote:
> 2016-10-28 13:50, Andrew Rybchenko:
>> First of all I'd like to double check that it is clear that we discuss
>> libefx
>> (base driver in terms of DPDK) import here. The PMD itself is already split
>> in 20+ patches.
> I don't know libefx. In DPDK,
2016-10-28 16:05, Andrew Rybchenko:
> On 10/28/2016 03:33 PM, Thomas Monjalon wrote:
> > 2016-10-28 13:50, Andrew Rybchenko:
> >> First of all I'd like to double check that it is clear that we discuss
> >> libefx
> >> (base driver in terms of DPDK) import here. The PMD itself is already split
> >>
2016-10-28 13:50, Andrew Rybchenko:
> First of all I'd like to double check that it is clear that we discuss
> libefx
> (base driver in terms of DPDK) import here. The PMD itself is already split
> in 20+ patches.
I don't know libefx. In DPDK, a base driver is often a subdirectory
inside the PMD.
Thomas,
On 10/27/2016 01:37 PM, Thomas Monjalon wrote:
> First of all, welcome to DPDK!
Thanks!
> 2016-10-27 09:34, Andrew Rybchenko:
>> we would like to include Solarflare libefx-based PMD in the DPDK 17.02
>> and start the upstreaming process.
>> The driver supports Solarflare SFN7xxx and SFN8
Hi,
First of all, welcome to DPDK!
2016-10-27 09:34, Andrew Rybchenko:
> Hi,
>
> we would like to include Solarflare libefx-based PMD in the DPDK 17.02
> and start the upstreaming process.
> The driver supports Solarflare SFN7xxx and SFN8xxx families of 10/40
> Gbps adapters.
> The driver has
Hi,
we would like to include Solarflare libefx-based PMD in the DPDK 17.02
and start the upstreaming process.
The driver supports Solarflare SFN7xxx and SFN8xxx families of 10/40
Gbps adapters.
The driver has base driver. It is just fresh version of the same code
which is used in the FreeBSD [1
13 matches
Mail list logo
