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 715194367C; Tue, 5 Dec 2023 19:30:34 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 048AB40297; Tue, 5 Dec 2023 19:30:34 +0100 (CET) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by mails.dpdk.org (Postfix) with ESMTP id AD23340271 for ; Tue, 5 Dec 2023 19:30:32 +0100 (CET) Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-6ce557298f6so1955275b3a.3 for ; Tue, 05 Dec 2023 10:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1701801031; x=1702405831; 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=2FjELR4bjyh8+ZSH+ZtXaKQ3SW4xsTY83AtqCmB91Yg=; b=LL+fDx8w4FrZr9nNuoxGk9ahasZ9cw8BpU0tTezvHjEi5ytE/wTt+Rp2MAkRW6kneH S+vCAJe9XXGpsXEzfM8IUXakk4goxwJLLcGYimnOCGnQLzRWAbxMH0Ave5kk/bWTfv/k cJj8xzGjsMXrgOCXFaeOLl92AhqMRCibq4NDXPqgAA8hgX7Va1mNcxjmxLlxVvuUEYQn Tf8u0DsrHgOo59UeEjNkT+I6rTyUEf2s+IM69KvVsRi3kCYKbp/Xg5OPm9wmwU77EQJ7 9S6xeJfS2qhrf/pU2v3w+cHhNOBkJOsV9uMqWXud0RwMBd6QYKfuomFeAMX8nkG4dha0 PZ8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701801031; x=1702405831; 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=2FjELR4bjyh8+ZSH+ZtXaKQ3SW4xsTY83AtqCmB91Yg=; b=RvmiPEdRafV3puSapuv1AbzEgk6WzWjUv0DBKF32nOCmlEOhtytSKGMzmRSFjETc1Q /JturLEtE0u7u/cdnT3IlDzmCvEWlWxsR+p8/j3Q8o5HAshvElpJKPR0YxYW48mcRu0H Rlt83h2jKbCPQipXU3BHX1x5DQVq9JcwuQfMs/T/BpGuUHdfVsjnVecc3WWSTCXgBMDq ODLlooUE60wTzu+l+5S+ZBtsQvZS69h/cPkIGvNPcQoc8aHx29sakOWmJcRVhTlwNvME ZPkD14csqc6uzUdGwc4l9QYQU8ArGeG54gfWA6GX0Qpk8tisqMYuA1pVL/4TsClQExNe mDSw== X-Gm-Message-State: AOJu0Yz4qZAN76Y9T40GeSZdAt1metPJULUYA6zwIYHw4o3v4ckvcJyl vWdgnkEkK4Qj9EOIysuVdR7XEA== X-Google-Smtp-Source: AGHT+IHqXmBI+iewU8cagH9efwrR60jXdUQB/5FgVYpCoiAG3sS6H6ZkciJuxjqn2xRC2KdtnLrJGg== X-Received: by 2002:a05:6a20:8e16:b0:18d:1321:c294 with SMTP id y22-20020a056a208e1600b0018d1321c294mr15312649pzj.20.1701801031371; Tue, 05 Dec 2023 10:30:31 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id hy5-20020a056a006a0500b0069343e474bcsm6103746pfb.104.2023.12.05.10.30.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 10:30:31 -0800 (PST) Date: Tue, 5 Dec 2023 10:30:29 -0800 From: Stephen Hemminger To: Maryam Tahhan Cc: ferruh.yigit@amd.com, lihuisong@huawei.com, fengchengwen@huawei.com, liuyonglong@huawei.com, shibin.koikkara.reeny@intel.com, dev@dpdk.org Subject: Re: [v2] net/af_xdp: enable a sock path alongside use_cni Message-ID: <20231205103029.1a5ce926@hermes.local> In-Reply-To: <20231204103101.2124374-1-mtahhan@redhat.com> References: <20231204103101.2124374-1-mtahhan@redhat.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 Mon, 4 Dec 2023 05:31:01 -0500 Maryam Tahhan wrote: > With the original 'use_cni' implementation, (using a > hardcoded socket rather than a configurable one), > if a single pod is requesting multiple net devices > and these devices are from different pools, then > the container attempts to mount all the netdev UDSes > in the pod as /tmp/afxdp.sock. Which means that at best > only 1 netdev will handshake correctly with the AF_XDP > DP. This patch addresses this by making the socket > parameter configurable alongside the 'use_cni' param. > Tested with the AF_XDP DP CNI PR 81. > > v2: > * Rename sock_path to uds_path. > * Update documentation to reflect when CAP_BPF is needed. > * Fix testpmd arguments in the provided example for Pods. > * Use AF_XDP API to update the xskmap entry. > > Signed-off-by: Maryam Tahhan Why does XDP PMD not use abstract socket path? Having actual file visible in file system can cause permission and leftover file issues that are not present with abstract path. If you use abstract path then when last reference is gone (ie server exits) the path is removed. With regular paths, the file gets stuck in the file system and has to be cleaned up.