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 6D1F54368B; Wed, 6 Dec 2023 16:00:19 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0AD14402A7; Wed, 6 Dec 2023 16:00:19 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 1174E4021E for ; Wed, 6 Dec 2023 16:00:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701874817; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rRg7+7Tt5r/YoOG1BpFUnFZtNFYtFGhb0LHwapID2aQ=; b=UHASup3ksmlwUo+FfYGHriX0h7y6W2hf50iAR3uosg9P4f+L3Ql+p0ETvGeFVCTUdrAKrI GZH366O2JmTtrDkiOn+NxLTHEX89CxZGlNMQjLAUcBZvrgp/t5lkBbk5O9+h5kzUhjEreX 4uTQhuIvAVOW2vLwtYaHbr/byYSuyyw= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-15-BxlbOFIuOFGfLmcFtoe5zw-1; Wed, 06 Dec 2023 10:00:14 -0500 X-MC-Unique: BxlbOFIuOFGfLmcFtoe5zw-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-40b4c9c3cffso50025995e9.2 for ; Wed, 06 Dec 2023 07:00:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701874813; x=1702479613; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rRg7+7Tt5r/YoOG1BpFUnFZtNFYtFGhb0LHwapID2aQ=; b=Cb5dbIW7EtALadhiCgbHeOS8jg2cBtdd3pzLrF9moPtgsAY/0WdqirfO1PUfPtOSLc 4Z+mfzLIl6IkLVr4w7Y2D8zU6VkYLCEFoXkI8WTAdXEeK3LgwA6m+DE8JFwJFbNnFfxx 5raxV+o0oHIBTjXH6Cp5yTuGJxhc3DTuYrqmbDWEbAhnhQ31t29owCmcC3ve4Y6ock71 +ai0YnaeQix3VrVxaQS7lhXkIAGAg+J9zfVemdXDaPKZKdjrDfirjcy5ClVx33oAE5Y0 JDvCZszxzvuqiDY+5kz7jWr2yGhHZJfbLGp/l+TGKXKmkolp5DwzvJKcIc0wL8dgZF5Z zsXg== X-Gm-Message-State: AOJu0YyDPsiIXKTB/KruHpAEI0/khohNBC4krGWMwbwsoGL776lEwPEE kGkW//3VYQxYlUlk5LSPKbwbVby4t5Vc6L9gckBs6rE3X6HcW1G+pqup5P871OvM3aW25ZsDkM7 S8T0= X-Received: by 2002:a05:600c:3317:b0:40b:5f03:b39c with SMTP id q23-20020a05600c331700b0040b5f03b39cmr322377wmp.190.1701874813659; Wed, 06 Dec 2023 07:00:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IG3rv+78mCjA9jstZWkd0YCmMUBaBDzIHHZiPlRHN/iArDloep5gKQyaD/RiOuk9f1DcV2CyA== X-Received: by 2002:a05:600c:3317:b0:40b:5f03:b39c with SMTP id q23-20020a05600c331700b0040b5f03b39cmr322372wmp.190.1701874813334; Wed, 06 Dec 2023 07:00:13 -0800 (PST) Received: from [192.168.0.12] ([78.18.22.228]) by smtp.gmail.com with ESMTPSA id q13-20020a05600c46cd00b004063c9f68f2sm22198456wmo.26.2023.12.06.07.00.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Dec 2023 07:00:13 -0800 (PST) Message-ID: Date: Wed, 6 Dec 2023 15:00:12 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [v2] net/af_xdp: enable a sock path alongside use_cni To: Stephen Hemminger Cc: ferruh.yigit@amd.com, lihuisong@huawei.com, fengchengwen@huawei.com, liuyonglong@huawei.com, shibin.koikkara.reeny@intel.com, dev@dpdk.org References: <20231204103101.2124374-1-mtahhan@redhat.com> <20231205103029.1a5ce926@hermes.local> From: Maryam Tahhan In-Reply-To: <20231205103029.1a5ce926@hermes.local> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 05/12/2023 18:30, Stephen Hemminger wrote: > 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. > Hi Stephen I've not seen abstract sockets being used in pod to pod communications in Kubernetes before. I would love to learn more if you have any references. In the scenario mentioned above, the AF_XDP Device Plugin (A pod that is the K8s entity on host provisioning and managing interfaces that want to use AF_XDP) manages access and cleanup for this uds path so there's no overhead on the XDP PMD side inside the DPDK pod. The AF_XDP DP uses file permissions on the host side to ensure that other processes/pods (that shouldn't) can't access the uds path for a specific pod. Both the AF_XDP DP and the DPDK Pod will have different network namespaces. Additionally, the actual path (on the host) and the mounted volume path in the container are not the same, on the Container side we set it up so that the path appears in a predictable location (which is the path mentioned above). I'm not sure I can do this with an abstract socket without picking a name/path that's entirely predictable on both ends? Just for clarity on what this UDS is used for -  this is the uds that's mounted into a the DPDK Pod/container as a volume, so that the XDP_PMD can "handshake" with the AF_XDP device plugin to get a FD for the xskmap that the PMD can use when it creates the AF_XDP socket (all this to remove elevated privileges being granted to the container). Thanks Maryam