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 3CB3A461F6 for ; Tue, 11 Feb 2025 11:58:14 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C619C40156; Tue, 11 Feb 2025 11:58:13 +0100 (CET) Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by mails.dpdk.org (Postfix) with ESMTP id 8D15540150 for ; Tue, 11 Feb 2025 11:58:12 +0100 (CET) Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-6dd0d09215aso41930896d6.2 for ; Tue, 11 Feb 2025 02:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739271492; x=1739876292; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AOeSjb86bALGvt2OKe2G45h1ND6s4gKMsMGzsGNO8yI=; b=TZYcvUTAbv7nIJ4fARvTJWJDsM2XwJGuom98NxBBCcWSxCso8q5bZKpmlGV15izKDa Y31Yx2lQhwsd6rNDleKyWh1FvMNV9hJshtRMHkJgnABICH7oKI86w7Xse4Vew8xVEV3Q c6s0ffK8vow0a0ROzGRqtjyoKqWxoaBy5FapWC5OTfTpZTwy4tjO/UWdnKDsybnKlxjm zc/BF5Nc04Ipk2obPEE4eQnhsCfhsdsiT1FKcoreD33tBqpW8xgnrqU5Co5iHfH5U6Ac KXg+k98Anw9HKGGYz/M0PfWX3UKV8YcTL8I/0Ee/vKLyDP6g19bRpq+BAERdTZ5wlZuY eSBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739271492; x=1739876292; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AOeSjb86bALGvt2OKe2G45h1ND6s4gKMsMGzsGNO8yI=; b=vxPBBjtHWgKOkSZTvzesWwa8T/ZdqIM8VOfkahYNATa1ZSscnuj28cvba1sb71NNwp cq24w8DEH3vqyVjwRW3yXQwp5vvUHex5ZfN+a3xtnnFLSeAPyvfla2BjkO9e6k4bkEA6 HMdS332MngIJyQxYIZs2PVExj4XPu5X7Pfo0L2Qk/snjzm+aDx8b2YJl6yJR4cctOBid 1GueO7OadTQlEVS+VfmE2LFtJzCSBHxr+AsoWODj+x6iOPUIjz78V8eUBr43joW8gD6T m8E/Texs+eWFifhSJJQu27dv7w9DlQF7XSnWm9YOhQets0Odie6ikw4vOHHg4cIp6vZp VKyQ== X-Gm-Message-State: AOJu0YxOZQVzXUpanRVzsXeQ2H0e2MTX22putrlsRkVe2ORUai5xw2r9 Jruv60IPdfV8gEruwkvj5vbrALpl77zm0zlDeuhbx5V0ydF8/biU2PXlxUqFBLk64MuVBN9PnNH hyduSSnfmYJUXsMKBv6v21lLSwqibAOM2 X-Gm-Gg: ASbGncsNss4UNfk1ga8Z84oSQmkLHri2ViFAfwaWVLgKYOGoydQCM/uSB08Iz0ITYB/ 49byEhJ/Bt15veE1FWt/erESvJ1MTS42bNIvaYGXPyYZF/RXxNL2pY3SKUlPT5O6PJWbRPg== X-Google-Smtp-Source: AGHT+IFrKllWemE+y2XuKiXXrWf7RpH8etT6ucEi37CJ8uy+GJDmBU805Cs/UumZ90v9Zv8/uYZdHoeWb8jG8/KDirc= X-Received: by 2002:ad4:5f4a:0:b0:6d8:d84d:d938 with SMTP id 6a1803df08f44-6e4456c5c4emr226159326d6.28.1739271491865; Tue, 11 Feb 2025 02:58:11 -0800 (PST) MIME-Version: 1.0 References: <20250205084957.02e14a3e@hermes.local> In-Reply-To: From: Pavel Vazharov Date: Tue, 11 Feb 2025 12:58:01 +0200 X-Gm-Features: AWEUYZk9mglUd6bITz2k4N7NgU3XOE-oQ55kw04odTozGapRnilLQWOlzViJ8LA Message-ID: Subject: Re: IPv4 flows per queue on top of RSS for ixgbe and i40e drivers To: Stephen Hemminger Cc: users Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On Tue, Feb 11, 2025 at 9:45=E2=80=AFAM Pavel Vazharov = wrote: > > On Wed, Feb 5, 2025 at 6:53=E2=80=AFPM Pavel Vazharov = wrote: > > > > On Wed, Feb 5, 2025 at 6:50=E2=80=AFPM Stephen Hemminger > > wrote: > > > > > > On Wed, 5 Feb 2025 18:21:33 +0200 > > > Pavel Vazharov wrote: > > > > > > > Hi there, > > > > > > > > We have a proxy application on top of DPDK where we use a symmetric > > > > RSS key to receive the packets for a given connection in both > > > > directions on a single queue. In addition to that, we've few IPv4 > > > > addresses where we need to receive their traffic on particular queu= es. > > > > We use the rte flows functionality with RTE_FLOW_ACTION_TYPE_QUEUE = to > > > > achieve that and it seemed to work with the DPDK ixgbe driver. > > > > However, today we tried the same application on top of DPDK i40e > > > > driver and this setup doesn't seem to work there. It prints the > > > > following errors: > > > > `i40e_flow_add_del_fdir_filter(): Conflict with existing flow direc= tor rules!` > > > > It seems that the i40e driver doesn't allow adding flow rules on to= p > > > > of the already set RSS. > > > > > > > > Can somebody suggest a way to achieve what we need with i40e: to us= e a > > > > symmetric RSS key for most of the traffic but to redirect the traff= ic > > > > for a few specific IPv4 addresses to particular queues? > > > > > > > > Thanks, > > > > Pavel. > > > > > > If you are mixing RSS and rte_flow the results are not well defined. > > > Many drivers treat all active queues (including those used by rte_flo= w) > > > as candidates for RSS. > > > > > > If you want to mix, the the safe way is: > > > - don't enable RSS in the device config (rx_mode) > > > - define an rte_flow rule with RTE_FLOW_ACTION_TYPE_RSS > > > with a match all > > > - define a rte_flow rule with RTE_FLOW_ACTION_TYPE_QUEUE > > > that matches the IP > > > and set rule priorities so that specific IP rule matches before > > > the match all. > > Thank you for this idea. I'll give it a try. > The proposed setup worked for NICs with e1000 and ixgb drivers but > with i40e driver it returns error "Not support priority.". > I poke through the code of the DPDK i40e driver and the > `i40e_flow_parse_attr` is called for every type of flow - rss, fdir, > etc. > And inside this function, there is this piece of code: > /* Not supported */ > if (attr->priority) { > rte_flow_error_set(error, EINVAL, > RTE_FLOW_ERROR_TYPE_ATTR_PRIORITY, > attr, "Not support priority."); > return -rte_errno; > } > So, it seems to me that the driver don't support any flows with priority. > > > > > You still maybe at risk of hardware quirks and driver incompatibiliti= es > > > which is part of the problem with rte_flow. Just for the record I found the core of my issue with the i40e driver. The reason for the message "Conflict with existing flow director rules!" was that I created the flows before starting the port. The latter worked for e1000 and ixgb drivers but failed for i40e driver due to the following reason: - The fdir rules for the created flows are put internally in a variable `fdir_list` - When the port is started the driver calls `i40e_fdir_filter_restore` which iterates over the `fdir_list` and tries to add again already added flows using `i40e_flow_add_del_fdir_filter` where `i40e_sw_fdir_filter_insert` fails and the above error is logged. So it seems that it's better if the `fdir_list` is empty when the port is started and thus I moved the creation of the rte flows after the start of the port and the issue is gone. Thanks for the help and apologies for the possible confusion and time wasti= ng.