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 49917A0C50; Fri, 16 Jul 2021 14:34:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CD0EC4067B; Fri, 16 Jul 2021 14:34:43 +0200 (CEST) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by mails.dpdk.org (Postfix) with ESMTP id 62CCC40151 for ; Fri, 16 Jul 2021 14:34:42 +0200 (CEST) Received: by mail-io1-f44.google.com with SMTP id l5so10410724iok.7 for ; Fri, 16 Jul 2021 05:34:42 -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=KWxiYcFgbM4MD3JbUClOunwMzS3UmIwAprkArBBCboM=; b=Qb1zW9zc3FQMn1iJ5gA1hZ963oeqna/KJOK3oKgx+bSntApUeo5e730c/oWBFCqB6h zqQm3t0UJM6Y7FD1kEkY37qug2ABQHFRX/czDxFYHEGsD+5ytc2zPQp7iMyWiInLkyKu gh/mf6SQaY8CKOcsw/RfAIUvB6I71/PinNf3NxMSjrLJwB16jBgwuapfQuMWsn22rSZj w0I8ZtmxOZ+iJDRKnlNZzDzhPUyz+KF4RQZfJlIUpw19Jb9naGYG8he5UdFdEWGbHB00 mdgw3lqV4p700xAR8WiT96pnbCy3CAPY3N2Fo0AVtbAfnANf11GQg5Tr99N6G5LrE1zT NSlA== 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=KWxiYcFgbM4MD3JbUClOunwMzS3UmIwAprkArBBCboM=; b=EEoQjLi4ynhULl8NnGmDCW8+tuuGWuNiNRXIHXkfFeB4WIqd1KGJWIczWMq23SSB5e EPEgafStjaQ/xZ3kran5mrnYNyCh4JhKRykslpttFBhKbizM1H667WQSddl/WFzlkQ4X pp4h9VpQEzDDJw8NSHw++MerS3mzdJoG2zIw2I3rALLUZLfRy6uS3eW8KXjVtrMdtY4N zk4wmVcMR539rbCyDREsqSnx66igRnAZHQlpiAcogy2dOexKuD1UUN7+3UNQ2TrwypTj mH8M7tXzAyYnQtcL1gAOw1fX55gEvbBvIrUAN3vOtYB7O1F6+UC6Cl6UWrUDq6/1c2pb Yl3g== X-Gm-Message-State: AOAM532z7MxGQx4R+czf8gi8NfoTmTUEi4/9vTgExUMbOYKXa5I6iKA2 AGwm0EthRW9961nqaPj37gLnHBu1fm7d4H2m01A= X-Google-Smtp-Source: ABdhPJzkXdLUfVAZffEeefNswa7NtYTUJHVeo7qcAwc7yz00+sw1rptDJ+4JX8eGUvPq6OXs3rx6uRNqjWDHKisX6KA= X-Received: by 2002:a6b:7702:: with SMTP id n2mr7286835iom.1.1626438881749; Fri, 16 Jul 2021 05:34:41 -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: From: Jerin Jacob Date: Fri, 16 Jul 2021 18:04:14 +0530 Message-ID: To: Bruce Richardson Cc: fengchengwen , 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 3:20 PM Bruce Richardson wrote: > > On Fri, Jul 16, 2021 at 11:04:30AM +0800, 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 ? > > > The simple matter is that all devices must support ordering. Therefore all > devices must support the fence flag. If a device does all jobs in-order > anyway, then fence flag can be ignored, while if jobs are done in parallel > or out-of-order, then fence flag must be respected. A driver should never > return error just because a fence flag is set. > > > 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. > > > What you are describing is not a fence capability, but a limitation of the > hardware to enforce ordering. Even if we don't have fence, there is no > guarantee that one burst of jobs committed will complete before the next is > started as some HW can do batches in parallel in some circumstances. > > As far as I know, all currently proposed HW using this API either works > in-order or supports fencing, so this capability flag is unnecessary. I > suggest we omit it until it is needed - at which point we can re-open the > discussion based on a concrete usecase. > > If you *really* want to have the flag, I suggest: > * have one for fencing doesn't order, i.e. fence flag is ignored and the > device does not work in-order > * make it clear in the documentation that even if fencing doesn't order > it's still not an error to put in a fence flag - it will just be ignored. Since we have only two class of devices 1) By default fence is there between transfers 2) Need to explicitly add a fence. Since there is no device that does not support the fence. IMO, As Burce suggested we don't need a fence flag. In class (1) devices, for fastpath functions, RTE_DMA_OP_FLAG_FENCE will be NOP. > > /Bruce