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 270FDA0C50; Fri, 16 Jul 2021 14:41:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 109F340DDB; Fri, 16 Jul 2021 14:41:17 +0200 (CEST) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mails.dpdk.org (Postfix) with ESMTP id E7B4E4067B for ; Fri, 16 Jul 2021 14:41:15 +0200 (CEST) Received: by mail-io1-f50.google.com with SMTP id w22so2263212ioc.6 for ; Fri, 16 Jul 2021 05:41:15 -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=PG+LCMHj0EDD6WPNQjmQOdITSyvjdLWLmAm7EeFb2Y0=; b=CiQK0H84osLZMV15fjOLDpxs/wc6waGztfMPdXEptropMnmIyp3sVapZL9lzaixKM5 2jhX8+k3KLIvZGjxf49Iv/o4l8fG65mncbUAv44XROqbstN70s1Rm6eWi/rZ+mQePZoc dShRlqKsSPRrHxeCf9Z7dL9/FMCQ4h0MN6MIWxanQNgx5Yf1OKfDpCDfyeEQvsYq9SgV QrSw+oH8f2arbr+zI93AR0PZ0rYfGsrAIXqiT5vVUMSU7Z4RzLFeeAVCKbNOteWt7oLz HYKLgiqF4fpae6+MntokRAEFX1JkIZ+pRO92lGU+/OMfnSrAb5z2epl0tjx2cSIZ6ui7 dhPw== 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=PG+LCMHj0EDD6WPNQjmQOdITSyvjdLWLmAm7EeFb2Y0=; b=lkgivyqPAt8jLGDi2+Zj77iLuyLNRLdjU7ftov8JwORIHhzfmpUjuZAj9cjf1jhfaV Md2runOm8fY7LqTBGUV964H0zoWuUJOQtbrMWj5wSizpe2Qz8oAiQE8E02FmpvQOnlST gap+6IEdHEZ400/lKda3P7WPYdHLxqxxpANOJoNy/uXBo+oLW1/qUoGGbPg/QX4+viog yWAdlsnoBc/vd0gmnAWvrEMuBefpsA9cAV/P2m/PlO5rP3XO8ztSTt6/41pijBzWlO7b xhLaDa/fQn/k28LrsSEGmaHvM2OwItKKVrFh39s/eKNMH+vPGR6bbAyTKrP0K+Ml9UXW 2UPw== X-Gm-Message-State: AOAM532I8ZL7RnR1TeEEnagdzXpaNzRJkxd1bgJQGkiiFOTKj56GtUp/ IvNNBxK3utxAGPcam5MCwVzsS0C7BgTrFFfVzaM= X-Google-Smtp-Source: ABdhPJxaQD3qbfgXL5ytNmOVhjClTs1gDjvqJPLFF9e51YAh8zxLJZ6h7sKcUoNmwaJ1OHlTnJKSoGTFuVfL6NShG7A= X-Received: by 2002:a6b:db18:: with SMTP id t24mr7425482ioc.163.1626439275338; Fri, 16 Jul 2021 05:41:15 -0700 (PDT) MIME-Version: 1.0 References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1626363661-51103-1-git-send-email-fengchengwen@huawei.com> <0aa82990-566b-f471-129b-31fbc2410ecc@huawei.com> In-Reply-To: <0aa82990-566b-f471-129b-31fbc2410ecc@huawei.com> From: Jerin Jacob Date: Fri, 16 Jul 2021 18:10:48 +0530 Message-ID: To: fengchengwen Cc: Bruce Richardson , Thomas Monjalon , Ferruh Yigit , Jerin Jacob , Andrew Rybchenko , dpdk-dev , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Nipun Gupta , Hemant Agrawal , Maxime Coquelin , Honnappa Nagarahalli , David Marchand , Satananda Burla , Prasun Kapoor , "Ananyev, Konstantin" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v4] dmadev: introduce DMA device 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 Fri, Jul 16, 2021 at 8:34 AM fengchengwen wrote: > > On 2021/7/16 0:33, Bruce Richardson wrote: > > On Fri, Jul 16, 2021 at 12:04:33AM +0800, fengchengwen wrote: > >> @burce, jerin Some unmodified review comments are returned here: > >> > > [snip] > > > > >> 2. COMMENT: > + * @see struct rte_dmadev_info::dev_capa > >>> + */ > >> Drop this flag as unnecessary. All devices either always provide ordering > >> guarantee - in which case it's a no-op - or else support the flag. > >> > >> REPLY: I prefer define it, it could let user know whether support fence. > >> > > I don't see it that way. The flag is pointless because the application > > can't use it to make any decisions. If two operations require ordering the > > application must use the fence flag because if the device doesn't guarantee > > ordering it's necessary, and if the device does guarantee ordering it's > > better and easier to just specify the flag than to put in code branches. > > Having this as a capability is just going to confuse the user - better to > > just say that if you need ordering, put in a fence. > > > > If driver don't support fence, and application set the fence flag, What's > driving behavior like? return error or implement fence at driver layer ? > > If expose the fence capability to application, then application could decide > which option to use. e.g. commit the operations before the fence and make sure it completes, > or use another collaborative approach. > > I think in this manner, the driver implementation can be simplified. > > [snip] > > >> 4. > >> COMMENT: > + * @see RTE_DMA_DEV_TO_MEM > >>> + * @see RTE_DMA_DEV_TO_DEV > >> Since we can set of only one direction per vchan . Should be we make > >> it as enum to > >> make it clear. > >> > >> REPLY: May some devices support it. I think it's OK for future use. > >> > > +1 > > That may need a capability flag though, to indicate if a device supports > > multi-direction in a single vchannel. > > There are a lot of combinations, and I tend not to add a capability for multi-direction. > Currently, no device supports multiple directions, So can we delay that definition? Yes. IMO, we need to change the comment from "Set of supported transfer directions" to "Transfer direction" If channel supports multiple directions, then in fastpath we need another flag to select which direction to use. IMO, Since none of the devices supports this mode, I think, we should change the comment to "Transfer direction" > > [snip] > > thanks