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 49AD346250 for ; Mon, 17 Feb 2025 20:06:58 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CD4A640151; Mon, 17 Feb 2025 20:06:57 +0100 (CET) Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by mails.dpdk.org (Postfix) with ESMTP id 38EA9400EF for ; Mon, 17 Feb 2025 20:06:56 +0100 (CET) Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-2fa48404207so9397242a91.1 for ; Mon, 17 Feb 2025 11:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1739819215; x=1740424015; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=KmdquE5ngx/W8uNEFjYk3Q4A8LMJa3f8RMsJCrM+iQs=; b=vKHAkYKl7Yc8/FSzpbmA8YTQlgEqYpo3yqYombOFdlPDhv4O8wiyWeOrEKuEecXNCU 4G6VFHGsGSbs+sKzT7dFlNYAFqEebaiB9uKL4CY1mqK1mLSowlIjpz1+MwusHs10xHyE Nt7iwHetin9Vx/wBvWjs0mJ+3qSt+U7/AV3O9P8fzvW2Lw1q5FtK0glQD3hXXzHiUQy6 FAQNz92aIghqiXqYfNJJHXj8dbtvLKPuMM7ALKySsF7ZGWr/AOjwOKSGX4elRGqtAyuv L2cB8GQgtZtqdzXenn3fGNA8WtF3zaz6sdba9Do/HVcPTEfcO/29sb/qyNGBG8XLxNbw 9HFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739819215; x=1740424015; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KmdquE5ngx/W8uNEFjYk3Q4A8LMJa3f8RMsJCrM+iQs=; b=c7LIdhjrLc6CcPKhMncdgpioHrdyqNnAmdKMCj4x5VPc4DkmvLA3mlyTS2kO8DZySq Jp8Ps9lYdjGPBwOgvfSqNySa/9Dt+FhmkeEm6kiVYz207VpKOL59rpu1LGqk//wt5klC MBdDGhK+nIYW7CYh+OdonULvBE+k5u3XrSu3eKW205rh67Tezss+6UlSaJdXNIM0fDUJ bpRDNkCXC1sjvgYZn7gNii3mC3elb6NUUNI9hZjFCNowxmkjv8UFtlFzqp9nYepwzlZj UXql86ha5mFLb5UGWNJ0Q8afsF1O0rWgBH1l/DktnyklBYTN31nwTPU/C7JRjgeVAFZu 4l3A== X-Forwarded-Encrypted: i=1; AJvYcCX1lOc/UPYAVx6n+66GSvOK7FrYlEzpviP6MMS4GqMtupUAgfA9oH15Zu8kH3YepxO6TPTxbg==@dpdk.org X-Gm-Message-State: AOJu0YwtfY+nWx13SQL9fpcSEXbsLZ+SVaYa0+CFlNelGKMj5oWHaMFg 5yR4HgXr5EfHaA4p/C8/SMpuQ9cJVvojghcK8hk9okTvK/jdvT8qJEyGydGBCmU= X-Gm-Gg: ASbGncs2u+SSoGRT7SHxT8ojhADt4OppiesoPJhhjI165Ze/H+iYW2xuUk0PdPunndT J677BbugtXp8z3j4L5ftgN7Xgzyumyxu+MRauGV3iTiDVffhPtea36BntB7ygvHcxdwOskuwar9 sHwzVB3uzIELf77fLJEOpkbQnqOGCiwwtVtPVqHjtsb46Z2OtYto+Vu/bdSyRsRwTer+9lSX13I z0XJ69whWTZV0PFiPhs74T66X7Xa4PzLzZQO/Jn7EFZBY7RStSWnKj12iOzW5i5eq5v52IuhUDc UpnsNvH+kftX1engQbPdVS3Y7HxVI59DhTz9pSNW0mXc9ctFxTgCyE+GsKNHv0HfB+og X-Google-Smtp-Source: AGHT+IG/c+GxXkVe/3T2WFkRD/uX0haZz4MHqcFkWgiiRyeEGP+cemRb0wHkESeDUb0B53PiuwkLWA== X-Received: by 2002:a05:6a00:2e08:b0:725:cfd0:dffa with SMTP id d2e1a72fcca58-732617756b4mr13583984b3a.5.1739819215248; Mon, 17 Feb 2025 11:06:55 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-adb5a92d1absm6646468a12.66.2025.02.17.11.06.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Feb 2025 11:06:55 -0800 (PST) Date: Mon, 17 Feb 2025 11:06:52 -0800 From: Stephen Hemminger To: Changchun Zhang Cc: "Van Haaren, Harry" , NAGENDRA BALAGANI , "users@dpdk.org" Subject: Re: [External] : Re: Query Regarding Race Condition Between Packet Reception and Device Stop in DPDK Message-ID: <20250217110652.2f3eb077@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Mon, 17 Feb 2025 18:57:00 +0000 Changchun Zhang wrote: > Hi Harry, > > Can we call rte_eth_dev_rx_queue_stop() on a rx queue when a fast path is still polling the queue? The sequence on control and fast path cores would like: > Control path: > rte_eth_dev_rx_queue_stop(rx_queue_id); > ...waiting for draining of rx_queue... > rte_eth_dev_stop() > .... > > Fast path: > Keep calling rte_eth_rx_burst() > (I am expecting it will return 0 if queue is already drained and stopped) > No. The application needs to not call rx_burst when stop is being done. There rx_burst is a fast path with no additional checks and is intentionally not thread safe. You need to coordinate queue management inside the application.