From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74D9BC432BE for ; Thu, 2 Sep 2021 13:05:37 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id EF08561053 for ; Thu, 2 Sep 2021 13:05:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EF08561053 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 326844003E; Thu, 2 Sep 2021 15:05:36 +0200 (CEST) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by mails.dpdk.org (Postfix) with ESMTP id 66AAA4003C for ; Thu, 2 Sep 2021 15:05:34 +0200 (CEST) Received: by mail-io1-f41.google.com with SMTP id y18so2336197ioc.1 for ; Thu, 02 Sep 2021 06:05:34 -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=0D47/8+dzxDSIP2XnMsO68owmSLhKy/Gr8V1hKf21bc=; b=DEgZ7+1iOOl5THHIdXppcSOURlBDxhNTGElMyinMoYQmUkcu3UM3cqPTQFRbXmD1js Ntv+mBghWOgrS12d65Y3Q08HaRpfXnZuYJwywuy70yahFHFOOUad1nKRCMNiGb8vqVOM pYdjaSZLGhXFZjM9fe3EdJTC8xi6YE+y7Q/aV0kUPz+iQjvpEtT2mJLlVAuvWtFHQJzY JWjREZ86JsfZ9I7v2U+r5qT8AXgg+bkXkPXpZkjyA5lrzR/mr5rglz2pt2uw/9X7nRAC GOr+0xGoe+1xPRxLiyKYLhfVorprc+9qWFzeIhIhz3Twkbb8o39YPfyJQPzciOuELSzW l9oA== 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=0D47/8+dzxDSIP2XnMsO68owmSLhKy/Gr8V1hKf21bc=; b=c1jUFsquMI/O7vZXbHTxWjgwYmCIp5bGAuAl6z/Cbcqfbu3HxCt8UY492g8hyD/ycl nNNs8fgQBG6OyL7b7BLj3sEuimDCGb0FI1yN26OxLgmEe0K3GPjmUqT9vhRf1R1Jwg0Q UJ4T5PWdTz2LmHgka1X9LsxVoguHjxHUUlpsTzOpUSjtSq+n3wYMLUvxoTb1zzNl7JEE qAWx+sUmYxX5KWoHFVUpTHXul84RQBH1NJkwGwjj3+dBShn/2+fljU9RP+eryRfLdKsu NmAExQheTzHMiZttNrvL/dZsCawntQLr1M9RFaoIzFFkqnxoZpEMwXG92GVZaaVsGR/c /wgA== X-Gm-Message-State: AOAM5305JIQnK3UH2VC2u3FaUc4nlmfnSRrBAlw7LmHhyIhkPwG/gqSR VsZt/Qnzo2hervf1SrujBMEuVpwb6LBES7kOTEI= X-Google-Smtp-Source: ABdhPJw43bqSy2lxVltPMdlkXtksid3hpBm7DtDrM2sEmX3kAhhDsb961fwehw8imARV9oBb9TDHT0mnldkW7XId5EY= X-Received: by 2002:a02:9608:: with SMTP id c8mr2682193jai.133.1630587933626; Thu, 02 Sep 2021 06:05:33 -0700 (PDT) MIME-Version: 1.0 References: <20210826183301.333442-1-bruce.richardson@intel.com> <20210901163216.120087-1-bruce.richardson@intel.com> <20210901163216.120087-4-bruce.richardson@intel.com> In-Reply-To: From: Jerin Jacob Date: Thu, 2 Sep 2021 18:35:07 +0530 Message-ID: To: Bruce Richardson Cc: dpdk-dev , "Walsh, Conor" , "Laatz, Kevin" , fengchengwen , Jerin Jacob , Satananda Burla Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 3/6] app/test: add basic dmadev copy tests 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 Thu, Sep 2, 2021 at 5:13 PM Bruce Richardson wrote: > > On Thu, Sep 02, 2021 at 04:24:18PM +0530, Jerin Jacob wrote: > > > > I think 25us will not be enough, e.s.p If is PCI-Dev to PCI-Dev kind > > of test cases. > > Since it is the functional test case, I think, we can keep it a very > > higher range to > > support all cases. Maybe 50ms is a good target. > > > > Sure, no problem to push it up. If it turns out that all upstreamed drivers > implement the "idle" function we can remove the fallback option completely, > but I'll keep it for now and push timeout up. Do you really think it needs > to be in the (tens of )millisecond range? Even for tests going across PCI > would most transactions not complete in the microsecond range, e.g. 100 > usec? Based on busload and size of buffers the completion time can vary. I think, 1 ms could be good trade-off. Also, In the future some HW needs beyond that then we can increase.