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 83861A00C2; Sun, 22 May 2022 17:23:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 23B0540156; Sun, 22 May 2022 17:23:27 +0200 (CEST) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by mails.dpdk.org (Postfix) with ESMTP id 0CA5540040 for ; Sun, 22 May 2022 17:23:25 +0200 (CEST) Received: by mail-pg1-f181.google.com with SMTP id c22so11694148pgu.2 for ; Sun, 22 May 2022 08:23:25 -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=wlPxBDb87aPuOdU4GDTY0cX3XjFhRjZpNGE9z5f3i/0=; b=MRA0ebTGbgbcbHx1nwxeSgW6GivFVObLhseu9FmT+Fra3uc45L8MVcbo0USAScJ1zf SHNgvHd1uTyTmwLIau+FyvK1YSExaR+f8Z2tRsAFMP/XY7UCv7gAYRwLjesgP3KCaCXZ vK7UC7iTQM4tostFRQzcLz5wDR6O/P9dSaEEkv/eTzMJGV0XeZGROeikG+xdFd6nhs5M KzlEO6CCmZa3BCjI2a12lYUFqD/JmC8k6AepgiqrWyZ2SBJyQ+cldwel9ezQRaMkSSWU /5W4lO3vzkAVOKwUHkwSCdrcvvMhxIOoIizaMdUUOokjZCDElVP4uDyR0SDXsoI7UKVx Oq0A== 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=wlPxBDb87aPuOdU4GDTY0cX3XjFhRjZpNGE9z5f3i/0=; b=oD4eKvvnSgcAL/df0mI0ohoXqQYaojtJ3drxUiqwJUWn1E4dzPVpp02DZCcR1z0OGK o7oecIX+7JKfWpRhhbivONSyqkRoAJkDqw8qI0QKvExevVvjbXgCFTB0Fa2iGR9sWHD+ /cN4wQjX9qSqsPuE8whzvLdDF28xV+T359DrQxwcdi0jpzy/+lts6VPGUJHrqpmmHb8i TMD+z1l9bNVZJhAeXmjwpBCLlXMF+VJN88tXTcWYDxsXmVvQyH/vmPaoExMgEjBL0cav dIQyYG6zw1YqRbX4zJs0zFvAPnPpg3ZqV/4d9BdII75lJdup+icAgOCuCvDT7VxfFcL8 XcYA== X-Gm-Message-State: AOAM5303deYJ88+nHiLv/kh/bNL17HLPTCDUSBqtWRi+ihWetpi0dz/c nERtbNqL7MOExRKg/ivZH63UCQ== X-Google-Smtp-Source: ABdhPJzi2dxxfWQ6rsVzDLYM+8PiZhpKKRyVLuj5Djo2lzpUNogwasATXPiFhhscRz6QaFO7PLZ5Tg== X-Received: by 2002:a65:668b:0:b0:3f6:4026:97cd with SMTP id b11-20020a65668b000000b003f6402697cdmr15117139pgw.420.1653233005124; Sun, 22 May 2022 08:23:25 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id y24-20020a1709029b9800b001616b71e5e3sm3269936plp.171.2022.05.22.08.23.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 May 2022 08:23:24 -0700 (PDT) Date: Sun, 22 May 2022 08:23:21 -0700 From: Stephen Hemminger To: Spike Du Cc: , , , , , Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark Message-ID: <20220522082321.3cdb7693@hermes.local> In-Reply-To: <20220522055900.417282-4-spiked@nvidia.com> References: <20220506035645.4101714-1-spiked@nvidia.com> <20220522055900.417282-1-spiked@nvidia.com> <20220522055900.417282-4-spiked@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Sun, 22 May 2022 08:58:56 +0300 Spike Du wrote: > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h > index 04cff8ee10..687ae5ff29 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf { > */ > union rte_eth_rxseg *rx_seg; > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */ > + /** > + * Per-queue Rx limit watermark defined as percentage of Rx queue > + * size. If Rx queue receives traffic higher than this percentage, > + * the event RTE_ETH_EVENT_RX_LWM is triggered. > + */ > + uint8_t lwm; > + > + uint8_t reserved_bits[3]; > + uint32_t reserved_32s; > + uint64_t reserved_64s; > void *reserved_ptrs[2]; /**< Reserved for future fields */ > }; > Ok but, this is an ABI risk about this because reserved stuff was never required before. Whenever is a reserved field is introduced the code (in this case rte_ethdev_configure). Best practice would have been to have the code require all reserved fields be 0 in earlier releases. In this case an application is like to define a watermark of zero; how will your code handle it. Also, using 8 bits as percentage is different than how other API's handle this. Since Rx queue size is in packets, why is this not in packets? Also document what behavior of 0 is. Why introduce new query/set operations? This should just be part of the overall device configuration.