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 474E8A0520; Thu, 2 Jul 2020 15:07:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1C6321D617; Thu, 2 Jul 2020 15:06:57 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id AC4E81D5D1 for ; Thu, 2 Jul 2020 15:06:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593695213; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=h9JBp1NPmqDRp4hzqgHSUpNzkIEBpQ1sVM8GBmE9Mk0=; b=AR9jpClIfFHMbRNNshcYlyBG7Ts6Uqf6SS2p0tAmJVQqfysT6hpw2RCBEjEblwwOd9u0vr RPYDEvv2Ckt7scixVVcd/E8wsYW5oyMS9CHvTULG355RbRSpR14bkEgZ3rcQMAkLZxyX/0 K1cg/TtZ2aPBfBoTcuPTywZ3eWOyoec= Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-453-Z5tSzdtKOS-Rl749aBwQxg-1; Thu, 02 Jul 2020 09:06:52 -0400 X-MC-Unique: Z5tSzdtKOS-Rl749aBwQxg-1 Received: by mail-vs1-f69.google.com with SMTP id b185so6823007vsb.10 for ; Thu, 02 Jul 2020 06:06:52 -0700 (PDT) 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=h9JBp1NPmqDRp4hzqgHSUpNzkIEBpQ1sVM8GBmE9Mk0=; b=uPryWKVlcGKXDghOoLVC6l/WW/ZYXHm/UZTiBN2d49DhZ/vgbU2Go/Vc/9SQe79Iwp xeO4jyrJSNd9rluTrW4vOCmUg4gragOS7s4VP+WU+NTjBIfqSmU97rSqNEElg5ZTvR5G sK1e9z+dXTATTbUBGAj9l83Xu57/5ZPXdi/z3RCxIXLO0G0pdFYHI07dKsbUqX5iLEdo d0jVpDJiNz1tSd/cmzLtLshlrRIfn+OpAwf8wY+E8Rc2Kf6KCoqD9tfCyo3wujW8GU6+ RSgQ5E7y+5WEuGTGOPA/XiXlkxPujfnAjkn78RIVjZH8GOLSSHvu5cmxERN8Q6vpZi0n W1KQ== X-Gm-Message-State: AOAM530Jnb8SyvrhMaEkay3ylPagjso33iQD9LEMD0lqjRf1HWw+yxTB Cs8Kf1JOohrkA2DX/BYE3khgVtx8+S0NNK/XwSV+EGB966j9h5Z5n+aVeTFq40tVMlFUcJUqOpg TiP69mFyn3LGF9kaW0ts= X-Received: by 2002:a1f:255:: with SMTP id 82mr22691225vkc.39.1593695211921; Thu, 02 Jul 2020 06:06:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwTmAsVau3Uz4BYDPRJLDWacX04cUwtN4bCRDVxB8omKrX6DRNSbvCdxx2KdvUlc55JCT2WMecSAYVXtWywQj8= X-Received: by 2002:a1f:255:: with SMTP id 82mr22691197vkc.39.1593695211651; Thu, 02 Jul 2020 06:06:51 -0700 (PDT) MIME-Version: 1.0 References: <20200610144506.30505-1-david.marchand@redhat.com> <2939263.AvGHZF5Fiy@thomas> <2881429.9YLJUJncU7@thomas> In-Reply-To: From: David Marchand Date: Thu, 2 Jul 2020 15:06:40 +0200 Message-ID: To: "Ananyev, Konstantin" Cc: Thomas Monjalon , "dev@dpdk.org" , "jerinjacobk@gmail.com" , "Richardson, Bruce" , "mdr@ashroe.eu" , "ktraynor@redhat.com" , "Stokes, Ian" , "i.maximets@ovn.org" , "Mcnamara, John" , "Kovacevic, Marko" , "Burakov, Anatoly" , Olivier Matz , Andrew Rybchenko , Neil Horman Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 6/9] eal: register non-EAL threads as lcores 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 Wed, Jul 1, 2020 at 1:58 PM Ananyev, Konstantin wrote: > > If the final users finally hit the situation you describe, it means > > that the multiprocess had been in use so far and was known to be in > > use (*hopefully*). > > Yes. > > > So is it not a problem of design/non-regression testing when > > integrating the new API in the first place? > > Not sure I understand you here... > If you saying that for SP benchmarking/testing current approach > is sufficient, then - yes it is. > Or are you saying it would be hard to create a test-case to > reproduce such problematic scenario? I am saying that getting to a problematic scenario that only the final users get, would be a failure in the development, documentation and validation of the application. When the developer integrates this new API, the developer will read the API description. - If the limitation on mp is understood and accepted, the application documentation will be updated to reflect this. Users can then know mp is not available. If the users still try to use it, it can be a support issue. The users will then report to support people who should be aware this is not supported (the documentation says so). - If the application needs mp support because of X, Y reasons, the developer integrating the new API, should complain upstream that the new API requires mp support. If the developer does not complain but still uses the API.. well too bad (or it falls through to the following point). - The application needs mp support, the developer did not catch the warning in the API (the kids are home, hard to concentrate)... The new API will be used for datapath processing threads, so non regression perf tests will be run. On the other hand, the application uses mp for X, Y reasons, so there will be associated test cases. I can't tell for sure, but I find it hard to believe a validation team would never do tests that combine both. -- David Marchand