From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrzej Ostruszka <amo@semihalf.com>
Subject: Re: [PATCH v4 1/8] net/mvneta: add neta PMD skeleton
Date: Thu, 20 Sep 2018 09:45:26 +0200
Message-ID: <b56298fc-1eb3-0de9-173b-c7edbc1e7b88@semihalf.com>
References: <1535720386-18775-1-git-send-email-amo@semihalf.com>
 <1537369294-17099-1-git-send-email-amo@semihalf.com>
 <1537369294-17099-2-git-send-email-amo@semihalf.com>
 <20180919091950.4e41de71@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, mw@semihalf.com, zr@semihalf.com, tdu@semihalf.com,
 nadavh@marvell.com
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com
 [209.85.167.66]) by dpdk.org (Postfix) with ESMTP id BFF4B5B3C
 for <dev@dpdk.org>; Thu, 20 Sep 2018 09:45:28 +0200 (CEST)
Received: by mail-lf1-f66.google.com with SMTP id b12-v6so135916lfa.4
 for <dev@dpdk.org>; Thu, 20 Sep 2018 00:45:28 -0700 (PDT)
In-Reply-To: <20180919091950.4e41de71@xeon-e3>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Thank you Stephen for taking a look at these patches.

On 19.09.2018 18:19, Stephen Hemminger wrote:
> On Wed, 19 Sep 2018 17:01:27 +0200
> Andrzej Ostruszka <amo@semihalf.com> wrote:
[...]
>> +     git clone https://github.com/MarvellEmbeddedProcessors/linux-marvell.git -b linux-4.4.52-armada-17.10
>> +
> 
> In general the rule for DPDK is that drivers in upstream DPDK must have their OS support
> components upstream. You are relying on an old Linux kernel which is maybe the way embedded
> works, but it really needs to be upstream first.

If this rule holds then there are some exceptions e.g. mvpp2 (in current
release using the same version of kernel) so accepting this driver will
not brake this rule any more than it is now.

AFAIK Marvell is using some parts that are not upstreamable so it will
be always a custom kernel - but I'm not competent enough to claim that
authoritatively.  In mvpp2 we have just recently switched to newer
kernel (just applied to next-net) and with enough of testing mvneta will
switch to it too.

So I hope this is not a blocker.

Best regards
Andrzej