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 9B37F43262; Wed, 1 Nov 2023 17:08:55 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2475640282; Wed, 1 Nov 2023 17:08:55 +0100 (CET) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by mails.dpdk.org (Postfix) with ESMTP id A9201400EF for ; Wed, 1 Nov 2023 17:08:53 +0100 (CET) Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-6b77ab73c6fso936803b3a.1 for ; Wed, 01 Nov 2023 09:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1698854932; x=1699459732; 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=oZhvcz+DxFssA59P8Nn5828yxWZCPZqbLn1TQMVgitA=; b=NCca20VYbxo6TtZFb3pvD6aDYPEnq/IyQ7BzI53imzRB0xAkw6VcUg4iWBRcgGyn3u mHGpaVPZ0Zpj0PNzyiZTn3FZL6YcdEu49lD2vNTdLBq5QITrl9IP+dYDw8BBh3KdB3pg akDDpAZ/SfD7LhgPTNpZlxFmJ5KYs7xb5/Bp+kX3RJIBqXdUkqWks7IOGPV7oq5EuVnn R5F+BusyvL0J5Bfn6231AHw1lt9aPBVyz84EMkbbf8tvh4qmnv3A4cEWMLew6vuOj0Mn DQ/J0w1f+MkNQf0uNgcwdLJTWx5Yequugl2CIg5N8uETQXT4iAw+DgLwLJRUuB3iaX7m a26A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698854932; x=1699459732; 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=oZhvcz+DxFssA59P8Nn5828yxWZCPZqbLn1TQMVgitA=; b=WAYZ36u3rBwbTZLayYixh5I96Hi9ze+UydKYd9Ha+AsyB7gi+yD6W/l6pE8jeiPoZt j6Em5izF8W9+jWJYXYWkezFs4dDJYtdWQA/W58tGdF5+0T+d2mQts/DMLf7rVZZvgKY6 3ktu0FpYiZAqYYUCAlGkUhnkgTgNEs2ED4CjZsKd/oxEtb7MhTBgmahIWc95JGKrwmd3 6plSr5Q3dOEOBnmiEetH7V9AJVnQtbcIHAK+GEe7lOvvh99HWJSYZeMFmxvyUR9yZtOQ PKKECUs4jsGM2l0+bmjIlnUwFp5PgAH/sUI85nsxUqpaDv6NwpDJrIl8UkN1khUb7sI/ DjPQ== X-Gm-Message-State: AOJu0YzTtVxpnmWtmJwejetCbpP9fXaIzoyxU2Cz4dsBu2syoPGAZmMt /CiMZeZ7hi+kWAP8ghe6F7tOQg== X-Google-Smtp-Source: AGHT+IHcbiq1E/LBz9arFVCeCxmJS+KDbZzVGLF4MNFeGZCsg/EDDjJt+3JnyK2PjJ1AsvRVGliQcQ== X-Received: by 2002:a05:6a00:6ca1:b0:6c2:e263:5c3d with SMTP id jc33-20020a056a006ca100b006c2e2635c3dmr4037987pfb.0.1698854932618; Wed, 01 Nov 2023 09:08:52 -0700 (PDT) Received: from fedora ([38.142.2.14]) by smtp.gmail.com with ESMTPSA id m25-20020a639419000000b0058d26647e45sm86561pge.54.2023.11.01.09.08.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Nov 2023 09:08:52 -0700 (PDT) Date: Wed, 1 Nov 2023 09:08:47 -0700 From: Stephen Hemminger To: "lihuisong (C)" Cc: , , , , , Morten =?UTF-8?B?QnLDuHJ1cA==?= Subject: Re: [PATCH v3 0/3] introduce maximum Rx buffer size Message-ID: <20231101090847.105f0fa1@fedora> In-Reply-To: References: <20230808040234.12947-1-lihuisong@huawei.com> <20231028014847.27149-1-lihuisong@huawei.com> <20231029084838.122acb9e@hermes.local> <20231030114850.799f2bce@fedora> <20231031084017.64b9f342@fedora> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) 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 Wed, 1 Nov 2023 10:36:07 +0800 "lihuisong (C)" wrote: > > Do we need to report this size? It's a common feature for all PMDs. > > It would make sense then to have max_rx_bufsize set to 16K by default > > in ethdev, and PMD could then raise/lower based on hardware. > It is not appropriate to set to 16K by default in ethdev layer. > Because I don't see any check for the upper bound in some driver, like > axgbe, enetc and so on. > I'm not sure if they have no upper bound. > And some driver's maximum buffer size is "16384(16K) - 128" > So it's better to set to UINT32_MAX by default. > what do you think? The goal is always giving application a working upper bound, and enforcing that as much as possible in ethdev layer. It doesnt matter which pattern does that. Fortunately, telling application an incorrect answer is not fatal. If over estimated, application pool would be wasting space. If under estimated, application will get more fragmented packets.