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 513CAA0032; Thu, 30 Sep 2021 00:38:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C019C40DDA; Thu, 30 Sep 2021 00:38:01 +0200 (CEST) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by mails.dpdk.org (Postfix) with ESMTP id 72D004067E for ; Thu, 30 Sep 2021 00:38:00 +0200 (CEST) Received: by mail-pf1-f179.google.com with SMTP id k17so3209524pff.8 for ; Wed, 29 Sep 2021 15:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=VuUHLIBRwEbYbQD48e6tevWALG7uSVeInEwZNdCszio=; b=5RDOgsIOCUIk94MctvdmeXWZYhEfsR1aH8kg61ZZlQH9feNe0KfXwhZtqXE0ln4osC Je2R5ypNAVMxO2mybpf6BlAmy9HI67mxufSkwyLIQ9evpDAtIb6qit2qdTVd+bLob5aU vKyc+5dhnPmJCQAEE7FtpumMOPHo/ksQK9Lde6cBW8wz/nAyYZSOFaFT0BWcNLnZRifU pMoCTMvg8xSUIElIahH71uz/uMdln3taibSBaRtlUQrZepOAMyTXCcPKVqoq4sYBQ7kZ TgDSYgZUqYsXMHVYdQCQX6ffR1bV9xyMUpX9by2e4JTinJjmH4KmeS+0rVGQwo5UcPim AUow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=VuUHLIBRwEbYbQD48e6tevWALG7uSVeInEwZNdCszio=; b=Ub37ktkmMW6NPpQfYkR/BMSfwL2TcalVeR7BHWN0OiAzftQSE6dWe2LV89O4PTiVn3 3uGcJRzmHYs2mF7dM7aChf92sSrzyN+tMQ6wHZ1A/wppHqdhQ4DIkAsnnp8F7OTxBz4u h6sUIEvp0LVEKofok0hcqcZm0crbMIWvWkGEnMGzJRKnJBADjNhD1sJaa+xuVpRVtBeL JUNOy4JCS6eshPsEIDJsc2q/Ht4OuRgzSKhR5cKyPpJY5Vk3EAGgVmhdoY3zKe/Pl5k5 7mJQtMF1Lknuu7GdGBQotSSlwsOexym186JXDa5pTMgil60Gh/kGWtqt+Z30rJIiGPj4 dbaw== X-Gm-Message-State: AOAM5318LgLcJq0A3UjkY9hNAkoigjgtO5Lu4FA0jcg8BKj5VoVecCpX PxLmukC/YhA8dJQUjMNq5HPzCw== X-Google-Smtp-Source: ABdhPJz9ZjO6W6kguHcE164oOb6Fxq/lGat3F9RMz3GGr5qwNXjr/chRLpsdZ4SMJWr9FexSexLhEA== X-Received: by 2002:a62:d14d:0:b0:44b:e32e:7c41 with SMTP id t13-20020a62d14d000000b0044be32e7c41mr1041148pfl.81.1632955079349; Wed, 29 Sep 2021 15:37:59 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id d5sm2783515pjg.53.2021.09.29.15.37.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 15:37:58 -0700 (PDT) Date: Wed, 29 Sep 2021 15:37:56 -0700 From: Stephen Hemminger To: Thomas Monjalon Cc: Ori Kam , dev@dpdk.org, andrew.rybchenko@oktetlabs.ru, ferruh.yigit@intel.com Message-ID: <20210929153756.0838d646@hermes.local> In-Reply-To: <2188270.3AJhsh48eD@thomas> References: <20210929104436.6fd88409@hermes.local> <2188270.3AJhsh48eD@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Querying for rte_flow support? 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 Wed, 29 Sep 2021 20:52:43 +0200 Thomas Monjalon wrote: > 29/09/2021 19:44, Stephen Hemminger: > > Have a problem with auto-detecting whether device driver supports rte_flow. > > > > Ideally in application would like to be able adapt to handle devices that > > do rte_flow and those that do not. If device does not support rte_flow, > > then configure with RSS across multiple cores; if device does support rte_flow > > then assign traffic to queue based on match (on MAC). > > > > The problem is that there really is not a good API in DPDK for checking. > > Most device drivers will not give the correct return to rte_flow_validate > > unless the device is configured already, and some require device to be started. > > In order to configure, the application has to choose how many queues to use > > and that is the reason it wants to know if rte_flow will work! > > > > The other alternative is looking at DPDK internal data structs to see > > if device supports flow operations. That is not good, and causes more > > issues in later releases. > > > > Looks like rte_flow has a "chicken/egg problem" here. > > I think we just need to fix drivers implementation of rte_flow_validate(). > We must be able to validate a flow before starting the device. > Which drivers are refusing such check? > That's something we can check with some unit tests. > > The issue is with Broadcom but I see it with others. Mostly because they validate the queue id in the flow request.