From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2EAD7A0576; Fri, 13 Mar 2020 19:04:11 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F16601BF97; Fri, 13 Mar 2020 19:04:09 +0100 (CET) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id 2A9041AFF for ; Fri, 13 Mar 2020 19:04:08 +0100 (CET) Received: by mail-io1-f68.google.com with SMTP id c19so9301919ioo.6 for ; Fri, 13 Mar 2020 11:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3mpnxU947lUUeJ31soUuZYMPtazXXs2SZoxp3XLqbl8=; b=lymn94RAr1UFVWXHECzW7/ykVLLP+bxXAmUeyFiAjxVJ90mkFNJe88JslhBq0uMY6I ZygdgvSKhkyCO5j7IX1Kb1KnmplO8yMvO5o5z5gFludeuAvgYIHVFI01Fi9mJxb49QeI Y0b+liCgnat8lnJ2fJop0UF1ioCn7opvHP7T2kh6P/9wXznvUFwOa/3VoQeuxANqr35o 6CwE4DObO7HnhzWIWwWqw7gwU5WYxd+KS3ebQkqkCUMQt1ZxRLxfwDNPpl25sZ0MhXip etOG4LXrpMKx7Ti1oKavPEJkDRy/8QYctrqjINZx35vhddDapue+1/6tgAeIW7rUFm3x giqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3mpnxU947lUUeJ31soUuZYMPtazXXs2SZoxp3XLqbl8=; b=DrK8kvzctkiV7qd5l//pWBN1ijcuoCMoLnqZjl2xz+G2uqbaFTUbtIWoDSLnEeETbp M5rAdoO7a+uYu5YZDeCEDjArn+jeCZOqUs91v85JoAiHUzyQNPvQdc8FEfCMBcbVyKSQ z2a5VgXgrSeii7l04Uh78c9PvWIAwNk5KCHjV4fYD/3AozAp9Au4erZcR3UUIa53FFW0 wJiuDOGo6WexmbHz/yesMCnqkOvEXknQ2P2aDFhs/XGsySBbU+h8sluKWmbMFcf9oUEd TjF2rLon87+UyTOctDT2RsD5Ur4P6Wh6Zv3jSY6CB6mhX4+PbTu8GFx9GxJ3zuFtwhAn sDaA== X-Gm-Message-State: ANhLgQ2I4gudtWQrninA0TTA9iu0IYV1bUkGnNPMd60WoEtTa1DQFQAx SVZLfcC+CyJW9io3kbFTOAuTl8v5jOqmOgIvyJ0= X-Google-Smtp-Source: ADFU+vv/2mlVEAwZ76yHcdtJg4Lyu3uliEPdZxI0OgJk4S+Y190B4/oWVuKhpd4u/xiWpLpgy1DcgcRyJy2Q1HIviQk= X-Received: by 2002:a05:6638:a2c:: with SMTP id 12mr14236141jao.60.1584122647224; Fri, 13 Mar 2020 11:04:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Fri, 13 Mar 2020 23:33:50 +0530 Message-ID: To: "Coyle, David" Cc: Shreyansh Jain , Hemant Agrawal , "dev@dpdk.org" , "stephen@networkplumber.org" , "Doherty, Declan" , "Trahe, Fiona" , "Ryan, Brendan" , "O'loingsigh, Mairtin" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC] Accelerator API to chain packet processing functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Mar 13, 2020 at 11:30 PM Coyle, David wrote: > > > > > On Fri, Mar 6, 2020 at 8:25 PM Coyle, David wrote: > > > > > > > > > > > > > /** Error Detection Algorithms */ > > > > > enum rte_rawdev_multi_fn_err_detect_algorithm { > > > > > RTE_RAWDEV_MULTI_FN_ERR_DETECT_CRC32_ETH, > > > > > > > > IMO, It does not make sense to add protocol specific stuff in rawdev > > > > symbols. > > > > > > > > IMO, It is better to have a separate library for CRC and BIP32 > > > > acceleration like the rte_security library and underneath still it > > > > can use rawdev or anydev if required. > > > > > > [DC] This protocol stuff is only in the rawdev interface definition, which is > > known only to the application and the rawdev PMDs which will use this > > interface. > > > So these defines/enums/structs etc for CRC and BIP are completely > > opaque to rte_rawdev itself. > > > > > > This is how all existing rawdev PMDs interfaces are defined, where the > > interface is very specific to the job(s) the PMD is implementing. > > > > If you see .map file in driver/raw/. None of the drivers are exposing any API > > with rte_rawdev_*. > > This addition will be exposing new rte_rawdev_* APIs from driver/rawdev/. > > That's is not correct. > > > > $ find drivers/raw/ -name *.map > > drivers/raw/skeleton/rte_rawdev_skeleton_version.map > > drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map > > drivers/raw/ntb/rte_rawdev_ntb_version.map > > drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map > > drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map > > drivers/raw/ioat/rte_rawdev_ioat_version.map > > drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map > > drivers/raw/ifpga/rte_rawdev_ifpga_version.map > > > > IMO, Correct thing to do will be, > > > > Either of > > > > 1) As mentioned below, If you would like to limit the scope only to a new > > rawdev driver then > > a) Create a new driver at driver/raw// > > b) expose the drier specific customer API as > > rte__...(example: > > drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map > > > > 2) If we would like to have public API then create a subsystem like libsecurity > > to have features. Let the API exposed from lib/... > > > > [DC] Yes you are right here, it was incorrect to include rawdev in the interface filename and in the symbols within... rawdev will be removed from all these > And we are going with option 1 above, to limit this to the new rawdev drivers. > As I mentioned in the original post, if it is found that this interface could be useful to other drivers/applications in the future, then it can be moved to the public API under lib as a new library or an extension of an existing one possibly +1