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 73DEE43C12; Fri, 1 Mar 2024 18:04:49 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C73CD42D66; Fri, 1 Mar 2024 18:04:48 +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 796F24025C for ; Fri, 1 Mar 2024 18:04:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709312687; 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: in-reply-to:in-reply-to:references:references; bh=6NqEI9vGPlqS9zpQuTs73oXGb5lkIqYJFkIl9j3ODtI=; b=ZaExzLdTU/KybI5p2En/9AtvLIkC4s8ij+S4f/I60VfVFSVpXhbUEYYlBWr/TO3G+k3cip QDNj+/cJZUcvIRAp6fQoPzVKBaAZH6RdceaVR7543plFYU2+1NTy5p+reAHlr16U0/u5Ts rt1O/qYx2HOsTD9s/LSLFI7Rnm+3tG8= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-655-F-nT7ypsPNKDox2mtcAEEQ-1; Fri, 01 Mar 2024 12:04:45 -0500 X-MC-Unique: F-nT7ypsPNKDox2mtcAEEQ-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4129b426bdaso13859845e9.0 for ; Fri, 01 Mar 2024 09:04:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709312684; x=1709917484; h=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=6NqEI9vGPlqS9zpQuTs73oXGb5lkIqYJFkIl9j3ODtI=; b=C8qR+wqsWXf791cQH1Xs3fGZvb69xrXySAiXaMwSpBrDuhtXtKvCH+d1VZhvphvWW6 Oe1keYaxdFB1oVFhaiBaazLuxX4+Xv8JExUkNwzs+jJoserOZMsdocmamFxKKcArCVJ9 UPHVVcJRnuWarDX3oVJ8OYTAiQJMa+M00FyEV0BD5Gn6tuk9sGOJnNQ18pbul+V7HDL3 NRvQ9uWpmAZ6UIpvarhRBAdDTdErI4Q7Jpp9jVjQZXSwk7KDO+lM9HPWWMdzXeK9PsbC hywtOtcIBJRNzUHL/JydwkTZhOHd6ju0NQYnQptpqdFL4IkqRi5eaW56upynope5wW+h bWqw== X-Gm-Message-State: AOJu0Yw8vugrJTaF9y7TWRYl7QW+cxJaEmXTdUqr9Loj+ETls6ptUgut EhXtAdK7XMzPl4oHPw0+KPuLaJLXyjoOAKENSAUAmh0ytW6qCRIBq+2XESTjvw+Xr603SfAEOz9 sTsjBsfyN66XxIxGdKLr0Qs2JoSpni70ZaOXksVr5 X-Received: by 2002:a05:600c:3b15:b0:412:a1c6:ecd with SMTP id m21-20020a05600c3b1500b00412a1c60ecdmr1718015wms.30.1709312684287; Fri, 01 Mar 2024 09:04:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IHu1eJ9gFlkWJh4daCdpudScGHiLmP4B8uf2XYPsOSSFBNovO/v/Tfcd95768xITcHdBKm3Ww== X-Received: by 2002:a05:600c:3b15:b0:412:a1c6:ecd with SMTP id m21-20020a05600c3b1500b00412a1c60ecdmr1718000wms.30.1709312683953; Fri, 01 Mar 2024 09:04:43 -0800 (PST) Received: from [192.168.0.4] ([78.18.30.42]) by smtp.gmail.com with ESMTPSA id p15-20020a05600c468f00b00412b0e51ef9sm6077200wmo.31.2024.03.01.09.04.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Mar 2024 09:04:43 -0800 (PST) Message-ID: <3c3842f4-4b9d-4a29-a84a-c5b84e4051d7@redhat.com> Date: Fri, 1 Mar 2024 17:04:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [v11 2/3] net/af_xdp: fix multi interface support for K8s To: "Loftus, Ciara" , "ferruh.yigit@amd.com" , "stephen@networkplumber.org" , "lihuisong@huawei.com" , "fengchengwen@huawei.com" , "liuyonglong@huawei.com" , "Marchand, David" , "Koikkara Reeny, Shibin" Cc: "dev@dpdk.org" , "stable@dpdk.org" References: <20240229132129.656166-1-mtahhan@redhat.com> <20240229132129.656166-3-mtahhan@redhat.com> From: Maryam Tahhan In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------XFnysHe7mlzwMehBEZEFulnT" Content-Language: en-US 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 This is a multi-part message in MIME format. --------------XFnysHe7mlzwMehBEZEFulnT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 01/03/2024 15:43, Loftus, Ciara wrote: > snip > >> @@ -1695,17 +1699,16 @@ xsk_configure(struct pmd_internals *internals, >> struct pkt_rx_queue *rxq, >> } >> >> if (internals->use_cni) { >> - int err, fd, map_fd; >> + int err, map_fd; >> >> - /* get socket fd from CNI plugin */ >> - map_fd = get_cni_fd(internals->if_name); >> + /* get socket fd from AF_XDP Device Plugin */ >> + map_fd = uds_get_xskmap_fd(internals->if_name, internals- >>> dp_path); >> if (map_fd < 0) { >> - AF_XDP_LOG(ERR, "Failed to receive CNI plugin fd\n"); >> + AF_XDP_LOG(ERR, "Failed to receive xskmap fd from >> AF_XDP Device Plugin\n"); >> goto out_xsk; >> } >> - /* get socket fd */ >> - fd = xsk_socket__fd(rxq->xsk); >> - err = bpf_map_update_elem(map_fd, &rxq->xsk_queue_idx, >> &fd, 0); >> + >> + err = xsk_socket__update_xskmap(rxq->xsk, map_fd); > Hi Maryam, > > I've reviewed the series again. I haven't tested the device-plugin specific functionality as I don't have that environment set up, but outside of that I am happy that the new functionality doesn't break anything else. The doc updates look good to me now, thank you for the fixes. > > I have just spotted one issue and I apologise for only catching it now. > Patch 2 introduces a dependency on the xsk_socket__update_xskmap function which is available in: > libbpf >= v0.3.0 and <= v0.6.0 > libxdp > v1.2.0 > > The af_xdp.rst guide states we are compatible with libbpf (on it's own) <= v0.6.0. So users using libbpf < v0.3.0 will get an undefined reference warning for the xsk_socket__update_xskmap function. > > Is it possible to implement fallback functionality (or if that's not possible, bail out) if that function is not available? See how this is done for the xsk_socket__create_shared function in meson.build and compat.h. > > Thanks, > Ciara > Hi Ciara Yeah, no prob - I can re introduce the ``bpf_map_update_elem()`` call as a fall back. I will need to retest the permissions as I remember escalated permissions being required when issuing that call directly in the PMD which is why I moved it to using ``xsk_socket__update_xskmap()`` but let me retest and circle back with some changes. :) Looks like we are going to a v12 :) BR Maryam --------------XFnysHe7mlzwMehBEZEFulnT Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 01/03/2024 15:43, Loftus, Ciara wrote:
snip


@@ -1695,17 +1699,16 @@ xsk_configure(struct pmd_internals *internals,
struct pkt_rx_queue *rxq,
 	}

 	if (internals->use_cni) {
-		int err, fd, map_fd;
+		int err, map_fd;

-		/* get socket fd from CNI plugin */
-		map_fd = get_cni_fd(internals->if_name);
+		/* get socket fd from AF_XDP Device Plugin */
+		map_fd = uds_get_xskmap_fd(internals->if_name, internals-

dp_path);

 		if (map_fd < 0) {
-			AF_XDP_LOG(ERR, "Failed to receive CNI plugin fd\n");
+			AF_XDP_LOG(ERR, "Failed to receive xskmap fd from
AF_XDP Device Plugin\n");
 			goto out_xsk;
 		}
-		/* get socket fd */
-		fd = xsk_socket__fd(rxq->xsk);
-		err = bpf_map_update_elem(map_fd, &rxq->xsk_queue_idx,
&fd, 0);
+
+		err = xsk_socket__update_xskmap(rxq->xsk, map_fd);

Hi Maryam,

I've reviewed the series again. I haven't tested the device-plugin specific functionality as I don't have that environment set up, but outside of that I am happy that the new functionality doesn't break anything else. The doc updates look good to me now, thank you for the fixes.

I have just spotted one issue and I apologise for only catching it now.
Patch 2 introduces a dependency on the xsk_socket__update_xskmap function which is available in:
libbpf >= v0.3.0 and <= v0.6.0
libxdp > v1.2.0

The af_xdp.rst guide states we are compatible with libbpf (on it's own) <= v0.6.0. So users using libbpf < v0.3.0 will get an undefined reference warning for the xsk_socket__update_xskmap function.

Is it possible to implement fallback functionality (or if that's not possible, bail out) if that function is not available? See how this is done for the xsk_socket__create_shared function in meson.build and compat.h. 

Thanks,
Ciara


Hi Ciara

Yeah, no prob - I can re introduce the ``bpf_map_update_elem()`` call as a fall back. I will need to retest the permissions as I remember escalated permissions being required when issuing that call directly in the PMD which is why I moved it to using ``xsk_socket__update_xskmap()`` but let me retest and circle back with some changes.

:) Looks like we are going to a v12 :)

BR Maryam

--------------XFnysHe7mlzwMehBEZEFulnT--