From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 659B1A0503; Thu, 19 May 2022 09:40:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 56CA540150; Thu, 19 May 2022 09:40:23 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 56DC440140 for ; Thu, 19 May 2022 09:40:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652946021; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mNFZ791x1tIBZN/U/Hj9NjcaEWXPLfcV5tG4Vuf8Vlo=; b=KYSQfoKKJqTGmAt0iuxorRlFb4q50N7lS4zh8aJ6uk/UfCV0Rhn9cIHtlmFaR8kKD6JKOV vVZLvm9ZQDZuooa96okbMiLQZ5amOLlcpLmMQwMcITtfRr6uLCiKE8Q03v7pu6QGmRay0K tP6I4/uHkGZDHlJ/aFJdbarX3A0iGSA= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-491-sAO_ho2qNvWKlPTDu2FJSQ-1; Thu, 19 May 2022 03:40:20 -0400 X-MC-Unique: sAO_ho2qNvWKlPTDu2FJSQ-1 Received: by mail-lf1-f72.google.com with SMTP id e10-20020a05651236ca00b00474337bbe36so2282357lfs.2 for ; Thu, 19 May 2022 00:40:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mNFZ791x1tIBZN/U/Hj9NjcaEWXPLfcV5tG4Vuf8Vlo=; b=B1Dy6N1DM98ZgftGZOu0mtYO/+SIUdyORqMlrjFau/FSmp+2iA6EJrT+tgt9mzxms6 9moL7jaiq2Og+w1RTygpO5AgpdWjwfsyu8ViafpRZz5UAPbL+JavzMgzeok9V0DUFvwF Hfa6RgUzCCFAAwFnZJ2BVrYv46iPOEWXjZV8JgOyOS8Y3dSRwv2O3+Mr+vHSPNuE/iws Nkool8B38BhwckHRYLFCr8y5xoN5NsoLBtMiOvUrgKHV5Cz07Dv98W2YMUEXwZqyUHqt Z0cnLfqe9uKOKiwwWmqChINIeW9dPZirZmz3FyCC+l2UfHU8ecQLIIEF1nyX+MMjqqID gSFw== X-Gm-Message-State: AOAM531QUkLU01SU94HPKgv3yFHw5tO/qLOOXSYyKM7eylX3z7AE67L/ 8G53vHwkOqdECh1X3Fo28kW5gQTz/HbIReBakLC0F3ORt2wf3cip7p+zpd098w6qQJepD07NcQo yj4E1EfD9EDK6/nyYDnc= X-Received: by 2002:a05:651c:1781:b0:247:daa7:4358 with SMTP id bn1-20020a05651c178100b00247daa74358mr1843389ljb.477.1652946019161; Thu, 19 May 2022 00:40:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxy7Z2mLc1xMvWFTUlzeqXOchvSQYOcS4Pcuh+HV+4qOhM759ezoITSWPLpnULUTSy0NUUiNDbDpjzQRjdzuuM= X-Received: by 2002:a05:651c:1781:b0:247:daa7:4358 with SMTP id bn1-20020a05651c178100b00247daa74358mr1843373ljb.477.1652946018958; Thu, 19 May 2022 00:40:18 -0700 (PDT) MIME-Version: 1.0 References: <20220513075718.18674-1-david.marchand@redhat.com> <20220513075718.18674-3-david.marchand@redhat.com> <581f038e-a50a-175e-8336-c82f617954f5@yandex.ru> In-Reply-To: <581f038e-a50a-175e-8336-c82f617954f5@yandex.ru> From: David Marchand Date: Thu, 19 May 2022 09:40:07 +0200 Message-ID: Subject: Re: [RFC PATCH 2/4] net/bonding: move testpmd commands To: Konstantin Ananyev Cc: "Min Hu (Connor)" , dev , Thomas Monjalon , Xiaoyun Li , Aman Singh , Yuying Zhang , Chas Williams Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, May 19, 2022 at 1:25 AM Konstantin Ananyev wrote: > 18/05/2022 18:24, David Marchand =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Fri, May 13, 2022 at 12:10 PM Min Hu (Connor) w= rote: > >> > >> I think net/bonding offer 'API' for APP to use the bonding. > >> and use the specific PMD as slave device. > >> The software framwork is like: > >> APP > >> ethdev > >> bonding PMD > >> PMD > >> hardware > >> > >> so, I think cmdlines for testpmd should not put in net/bonding.be > > Actually, I feel the same. > I do understand the intention, and I do realize it is just location, > but still doesn't look right for me. > can't we have a special sub-folder in testpmd instead? > Something like app/testpmd/driver_specific/(ixgbe)|(i40e)|(bonding)... That should not pose a problem, indeed. And, on the plus side, it avoids putting some testpmd global variables in meson (which I was not entirely happy with). But, on the other side, I have a concern about MAINTAINERS updates. (almost) everything in app/test-pmd has been under the testpmd maintainer responsibility. Separating the driver specific code from testpmd is a way to clearly shift this responsibility to the driver maintenance. One advantage of moving the code to the driver directory is that there is no MAINTAINERS update needed. If we keep those in app/test-pmd, it is still possible to mark the driver-specific sources in MAINTAINERS, but such updates are often missed. I can probably add something in devtools/ to catch those updates in the future... I'll try for RFC v3. --=20 David Marchand