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 76FDAA0548; Sun, 31 Oct 2021 23:19:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EFB9C4068E; Sun, 31 Oct 2021 23:19:39 +0100 (CET) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by mails.dpdk.org (Postfix) with ESMTP id 1705F40689 for ; Sun, 31 Oct 2021 23:19:39 +0100 (CET) Received: by mail-il1-f177.google.com with SMTP id x9so9007739ilu.6 for ; Sun, 31 Oct 2021 15:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AYo/vR2XJVqY7vR5oO+neTP69l/8bcxTAOxLVMe5D6E=; b=C3Ln/64BpLjMN8UNSmsO3RSjOhibk258frzAsMymFBRojjPkneAN3J9tSBdq4ejYEi 9YMAL7s2DrCR3GtsfqJoGxnysRWVvmb1kVzFyLnMsDwnYs8+++BJ130niJU5L8w0Fhpm o/uBzbqDAxJqPydxND7TZ9NrJI8blVIhHjmdmxXsxjl78x6GXaQ9w+cAddAu26hclPsL RSwTZTAjjTjdR3bS3t3j2uWHdlebyzmdaiRFtgliN5otddhBXBy5FRA4U6RhBANfcdx3 LiUKUGVWzttqAnMJWDnDP4kCWAaCxoAO8/gns/tr28B9Ty7smmaOjM1syqSM9ta8PpQP Wwxg== 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; bh=AYo/vR2XJVqY7vR5oO+neTP69l/8bcxTAOxLVMe5D6E=; b=lWpICfUhSyAmM6nBiHeItuUpKGPH39hcOu4kmIup7Ud+xsX8Z1E0s6LGM6++ZtsTON Xwj+lzRTs57ktxE2kMJKZPWcBboIAiRKp2K72+SAOAeZ8S+fbY9VnXtNj11pMCQRtxw3 XiQz5RBwUfTc5Thpto50ApCu0HLHGN7Ehveh8LAWv7xo7moucQw7kp7MUz06ghH5rri3 S0RwnYD0JBfyiS8idakSRYtPqCic7OXaQwC5mSH50dupzPhHH3gAMaEaWvEP3ltfgQ+m g7d2J1WNW3V6kUcjzeJK7TbO2AsfPT+aalOZpGS3sbJc+sIbgoSEZeVfXqynJCzB3Nhn p04g== X-Gm-Message-State: AOAM531Jmem3QHZzNM5k75y3ygmZGGeKha8w1Q4d/N22cIDkQhEKoEk0 MzU420j5qWb6mknvgUq77lPkhCGVfDgBDsq/M7A= X-Google-Smtp-Source: ABdhPJxCb/qPtZWMMLGi7CIdpTJoFwbl69Ndj4xt7swAVwg81GynpXHB65XldUJGgNepIJk0WSywP+bzEaUijvBZkZw= X-Received: by 2002:a92:c56b:: with SMTP id b11mr6206036ilj.243.1635718778331; Sun, 31 Oct 2021 15:19:38 -0700 (PDT) MIME-Version: 1.0 References: <20211019181459.1709976-1-jerinj@marvell.com> <15147533.nJ1qs5LPEr@thomas> <6391601.jCN5kLYsqS@thomas> In-Reply-To: <6391601.jCN5kLYsqS@thomas> From: Jerin Jacob Date: Mon, 1 Nov 2021 03:49:12 +0530 Message-ID: To: Thomas Monjalon Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "jerinj@marvell.com" , "dev@dpdk.org" , "ferruh.yigit@intel.com" , "ajit.khaparde@broadcom.com" , "aboyer@pensando.io" , "andrew.rybchenko@oktetlabs.ru" , "beilei.xing@intel.com" , "bruce.richardson@intel.com" , "chas3@att.com" , "chenbo.xia@intel.com" , "ciara.loftus@intel.com" , "dsinghrawat@marvell.com" , "ed.czeck@atomicrules.com" , "evgenys@amazon.com" , "grive@u256.net" , "g.singh@nxp.com" , "zhouguoyang@huawei.com" , "haiyue.wang@intel.com" , "hkalra@marvell.com" , "heinrich.kuhn@corigine.com" , "hemant.agrawal@nxp.com" , "hyonkim@cisco.com" , "igorch@amazon.com" , "irusskikh@marvell.com" , "jgrajcia@cisco.com" , "jasvinder.singh@intel.com" , "jianwang@trustnetic.com" , "jiawenwu@trustnetic.com" , "jingjing.wu@intel.com" , "johndale@cisco.com" , "john.miller@atomicrules.com" , "linville@tuxdriver.com" , "keith.wiles@intel.com" , "kirankumark@marvell.com" , "oulijun@huawei.com" , "lironh@marvell.com" , "longli@microsoft.com" , "mw@semihalf.com" , "spinler@cesnet.cz" , "matan@nvidia.com" , "matt.peters@windriver.com" , "maxime.coquelin@redhat.com" , "mk@semihalf.com" , "humin29@huawei.com" , "pnalla@marvell.com" , "ndabilpuram@marvell.com" , "qiming.yang@intel.com" , "qi.z.zhang@intel.com" , "radhac@marvell.com" , "rahul.lakkireddy@chelsio.com" , "rmody@marvell.com" , "rosen.xu@intel.com" , "sachin.saxena@oss.nxp.com" , "skoteshwar@marvell.com" , "shshaikh@marvell.com" , "shaibran@amazon.com" , "shepard.siegel@atomicrules.com" , "asomalap@amd.com" , "somnath.kotur@broadcom.com" , "sthemmin@microsoft.com" , "steven.webster@windriver.com" , "skori@marvell.com" , "mtetsuyah@gmail.com" , "vburru@marvell.com" , "viacheslavo@nvidia.com" , "xiao.w.wang@intel.com" , "cloud.wangxiaoyun@huawei.com" , "yisen.zhuang@huawei.com" , "yongwang@vmware.com" , "xuanziyang2@huawei.com" , "pkapoor@marvell.com" , "nadavh@marvell.com" , "sburla@marvell.com" , "pathreya@marvell.com" , "gakhil@marvell.com" , "mdr@ashroe.eu" , "dmitry.kozliuk@gmail.com" , "anatoly.burakov@intel.com" , "cristian.dumitrescu@intel.com" , "honnappa.nagarahalli@arm.com" , "ruifeng.wang@arm.com" , "drc@linux.vnet.ibm.com" , "konstantin.ananyev@intel.com" , "olivier.matz@6wind.com" , "jay.jayatheerthan@intel.com" , "asekhar@marvell.com" , "pbhagavatula@marvell.com" , Elana Agostini Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC PATCH 0/1] Dataplane Workload Accelerator library 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 Sender: "dev" On Mon, Nov 1, 2021 at 3:25 AM Thomas Monjalon wrote: > > 31/10/2021 22:13, Jerin Jacob: > > On Mon, Nov 1, 2021 at 1:04 AM Thomas Monjalon wrote: > > > > > > 31/10/2021 15:01, Jerin Jacob: > > > > Since rte_flow already has the TLV concept it may not be new to DPDK. > > > > > > Where is there TLV in rte_flow? > > > > struct rte_flow_item { > > enum rte_flow_item_type type; /**< Item type. */ > > const void *spec; /**< Pointer to item specification structure. */ > > > > Type is the tag here and the spec is the value here. Length is the > > size of the specification structure. > > rte_flows spec does not support/need zero length variable at the end > > of spec structure, > > that reason for not embedding explicit length value as it is can be > > derived from sizeof(specification structure). > > Ah OK I see what you mean. > But rte_flow_item is quite limited, > it is not the kind of TLV with multiple levels of nesting. > Do you need nesting of objects in DWA? No. Currently, ethernet-based on host port has the following prototype[1] and it has array of TLV(not in continuous memory). For simplicity, we could remove legth value from rte_dwa_tlv and just keep like rte_flow and let the payload contain the length of the message if the message has a variable length. See rte_dwa_profile_l3fwd_d2h_exception_pkts::nb_pkts below. [1] +/** + * Receive a burst of TLVs of type `TYPE_USER_PLANE` from the Rx queue + * designated by its *queue_id* of DWA object *obj*. + * + * @param obj + * DWA object. + * @param queue_id + * The identifier of Rx queue id. The queue id should in the range of + * [0 to rte_dwa_port_host_ethernet_config::nb_rx_queues]. + * @param[out] tlvs + * Points to an array of *nb_tlvs* tlvs of type *rte_dwa_tlv* structure + * to be received. + * @param nb_tlvs + * The maximum number of TLVs to received. + * + * @return + * The number of TLVs actually received on the Rx queue. The return + * value can be less than the value of the *nb_tlvs* parameter when the + * Rx queue is not full. + */ +uint16_t rte_dwa_port_host_ethernet_rx(rte_dwa_obj_t obj, uint16_t queue_id, + struct rte_dwa_tlv **tlvs, uint16_t nb_tlvs); [2] example TLV for TYPE_USER_PLANE traffic. + /** + * Attribute | Value + * ----------|-------- + * Tag | RTE_DWA_TAG_PROFILE_L3FWD + * Stag | RTE_DWA_STAG_PROFILE_L3FWD_D2H_EXCEPTION_PACKETS + * Direction | D2H + * Type | TYPE_USER_PLANE + * Payload | struct rte_dwa_profile_l3fwd_d2h_exception_pkts + * Pair TLV | NA + * + * Response from DWA of exception packets. + */ +/** + * Payload of RTE_DWA_STAG_PROFILE_L3FWD_D2H_EXCEPTION_PACKETS message. + */ +struct rte_dwa_profile_l3fwd_d2h_exception_pkts { + uint16_t nb_pkts; + /**< Number of packets in the variable size array.*/ + uint16_t rsvd16; + /**< Reserved field to make pkts[0] to be 64bit aligned.*/ + uint32_t rsvd32; + /**< Reserved field to make pkts[0] to be 64bit aligned.*/ + struct rte_mbuf *pkts[0]; + /**< Array of rte_mbufs of size nb_pkts. */ +} __rte_packed; > > > > > I really liked rte_flow enablement of ABI combability and its ease of adding > > > > new stuff. Try to follow similar stuff which is proven in DPDK. > > > > Ie. New profile creation will very easy, it will be a matter of identifying > > > > the TLVs and their type and payload, rather than everyone comes with > > > > new APIs in every profile. > > > > > > > > > Why not use protobuf and its IDL to specify the interface? > > > > > > Yes I think it is important to discuss alternatives, > > > and at least get justifications of why TLV is chosen among others. > > > > Yes. Current list is > > > > 1) Very easy to enable ABI compatibility. > > 2) If it needs to be transported over network etc it needs to be > > packed so that way it is easy for implementation to do that > > with TLV also gives better performance in such > > cases by avoiding reformatting or possibly avoiding memcpy etc. > > 3) It is easy to plugin with another high-level programing language as > > just one API. > > 4) Easy to decouple DWA core library functionalities from profile. > > 5) Easy to enable asynchronous scheme using request and response TLVs. > > 6) Most importantly, We could introduce type notion with TLV > > (connected with the type of message See TYPE_ATTACHED, TYPE_STOPPED, > > TYPE_USER_PLANE etc ), > > That way, we can have a uniform outlook of profiles instead of each profile > > coming with a setup of its own APIs and __rules__ on the state machine. > > I think, for a framework to leverage communication mechanisms and other > > aspects between profiles, it's important to have some synergy between profiles. > > 7) No Additional library dependencies like gRPC, protobuf > > 8) Provide driver to implement the optimized means of supporting different > > transport such as Ethernet, Shared memory, PCIe DMA style HW etc. > > 9) Avoid creating endless APIs and their associated driver function > > calls for each > > profile APIs. > > >