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 8E7E743AC8; Fri, 9 Feb 2024 17:52:35 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 09F5542E6F; Fri, 9 Feb 2024 17:52:35 +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 BB43042E64 for ; Fri, 9 Feb 2024 17:52:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707497552; 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=G+QeugmQts/7x1iiYX9gvKVdMVKpjYihq7WAfid5b+k=; b=PJd3cT5MWRqg1uyS/eBtsoXE/Fg6KytAkoHaEUiCspskM+w1Bzh8guHyqPe/Z91/ktqghK J75KW1mpYowyY/LPptq/twO+mjRy2Jr7fV/eZOKiSuLFBQhlLvMTZt34haKwjXLCtUYYDq Ap3d0eXAvJY53ro+sb3WL+E6l7jqOe4= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-595-YBTm9QZmPZmiaCvSvBpmGw-1; Fri, 09 Feb 2024 11:52:19 -0500 X-MC-Unique: YBTm9QZmPZmiaCvSvBpmGw-1 Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-680b2c9b0ccso17731936d6.1 for ; Fri, 09 Feb 2024 08:52:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707497539; x=1708102339; 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=G+QeugmQts/7x1iiYX9gvKVdMVKpjYihq7WAfid5b+k=; b=bMx/t+v8jn8CQ68ZXZ2uo77OPgl1URUss8HrVRq+02vdWqRwY0lvDdhpYX4puEHQfE /wVCqHK+HCZkwqj87IYDFdIe7oHieNNIqpwdsuaXsh8HUCTbQ8RYBelYMAVq/I01fEsz MVHrgNp9gzm23Ra+HIDeDLRIl94hAmKnv4hjsSTEsY7lVKJtPiHhEUxO+A8PCs75L1y1 EO5rjdE5BwBBPXjAR0+ZOqmmHyRZVPv7ElZOd/GrAR7cbbXFOtHiCUhRhLK+ZOVE/F4z 5r8bNnSiXCGan0JI9r4AkJtgJtEP/5lrHS5zg79lLF6GEFj15lS2dvPcWcVwIowbB5mz /6xA== X-Gm-Message-State: AOJu0YxAAqoXlbEZjN458fWK5JuzSflz9QuEibmKJdplaK2xcAMkABhf b5WHDV2EBF+fkIDe3ffYISMLeAPpjuESX8R5ZnbDy08keFiwWf8BtwGnqRuSff04puQUZXZinNQ QTac+iK447NRK5h20LNNSc+KiUFOxaPfzFRX9ZdeM X-Received: by 2002:a0c:f04c:0:b0:68c:c757:bf2e with SMTP id b12-20020a0cf04c000000b0068cc757bf2emr1944507qvl.49.1707497538730; Fri, 09 Feb 2024 08:52:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IFnhA17kUKS8dlJBNvKXASehSqfap20DQiP0fZmEYXXa8z0TQXhXKudIvW9QAbJuvM855M6kQ== X-Received: by 2002:a0c:f04c:0:b0:68c:c757:bf2e with SMTP id b12-20020a0cf04c000000b0068cc757bf2emr1944493qvl.49.1707497538417; Fri, 09 Feb 2024 08:52:18 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXS+aHihZft4MrV/lsZhDJyh6uA2/lzhox0ykYGZXHfIpqSfFe86hp7m5lo2IrPuQVsAoHpcNUf+C/x53LHy+iLuQDHOB2/mDEfbIeF7ngAImRO8p7y2lJ+T7n0geRGU5fG+A0vjVSj+FY460fr0vlsHGGJ1gFE2pWZ3tbbnkfH76TTsGVuTD2vTHtLjCk6VThFw6qk7BuzHxouiqj8JC/pIGM9SI3Fu6CabbqT/hVtvtyG3YdJmsW79YkOfb4Lbbc994LTjamlfHgDy5+ItSkzb8oABxRnkWw3M28M1jZB1k9fl41d7oKE1hKnj1Srjle/8Zle4TF8xvKBKTlUaUqL29+RrU/jX2AAlQ== Received: from [192.168.0.12] ([78.18.30.42]) by smtp.gmail.com with ESMTPSA id w13-20020a0ce10d000000b0068cc18c6ba0sm975402qvk.48.2024.02.09.08.52.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Feb 2024 08:52:17 -0800 (PST) Message-ID: Date: Fri, 9 Feb 2024 16:52:15 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [v7 1/1] net/af_xdp: fix multi interface support for K8s To: "Loftus, Ciara" , Ferruh Yigit , "stephen@networkplumber.org" , "lihuisong@huawei.com" , "fengchengwen@huawei.com" , "liuyonglong@huawei.com" , "Marchand, David" Cc: "dev@dpdk.org" , "Koikkara Reeny, Shibin" , Kevin Traynor , Luca Boccassi References: <20231222110441.2507650-1-mtahhan@redhat.com> <6cd6ab2d-56ab-4afe-b0cd-05ab6b017469@amd.com> <89fd40d1-cc91-4390-9bc6-c60f24129ebb@redhat.com> <8a667d69-8543-4dd0-bc90-9929b670a261@amd.com> <37ebae5b-cfb0-48f9-bafb-855e59b6bdc9@amd.com> From: Maryam Tahhan In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------mEoP4svZRf745A0JXeMW5nF4" 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. --------------mEoP4svZRf745A0JXeMW5nF4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 09/02/2024 12:40, Loftus, Ciara wrote: >> Hi Maryam, >> >> How do you want to continue with the patch, I think options we considered: >> >> 1. Fix 'use_cni' documentation (which we can backport to LTS) and >> overload the argument for new purpose. This will enable new feature by >> keeping backward compatibility. And requires new version of this patch. >> >> 2. If the 'use_cni' is completely broken in the 23.11 LTS, which means >> there is no user or backward compatibility to worry about, we can merge >> this patch and backport it to LTS. >> >> 3. Don't backport this fix to LTS, merge only to current release, which >> means your new feature won't be available to some users as long as a few >> years. >> >> >> (1.) is most user friendly, but if 'use_cni' already broken in LTS we >> can go with option (2.). What do you think? >> >> >> >> btw, @Ciara, @Maryam, if (2.) is true, how we end up having a feature >> ('use_cni' dev_args) completely broken in an LTS release? > My understanding is that the use_cni implementation that is available in the 23.11 LTS is compatible with a particular version of the afxdp-plugins-for-kubernetes source. Maryam's change makes it compatible with the latest version. @Maryam can you confirm this? > If my understanding is correct then I think we should include the version/tag/commit-id of afxdp-plugins-for-kubernetes that the code is compatible with. Including backporting a patch to LTS to specify what version that code is comaptible with. Yeah that's correct, the existing use_cni implementation would work with a particular version of the AF_XDP Device Plugin (with the limitation that the DPDK pod cannot request multiple interfaces from different device pools). From a deployment POV - I would consider this a broken behaviour. Non the less we can document it more explicitly. The use_cni changes I'm making now will enable multi interface support (for a DPDK pod, keeping backward compatibility in mind). It will also still work with the older version of the AF_XDP device plugin (with the 1 interface limitation for the DPDK pod). I will document all of these in the next revision. In addition to the changes mentioned above, I'm also extending the AF_XDP PMD to support retrieving the xskmap FD from a pinned BPF map (A new feature in the AF_XDP Device Plugin). All the above will be pushed in another revision of the patchset shortly (in addition to documentation changes). I'm just running tests and breaking down the patches into (hopefully) logical chunks. And lastly there's one other issue that I'm trying to also investigate/resolve - which is the AF_XDP Device Plugin integration under AF_XDP PMD doesn't support busy polling. That's probably another feature to add. >>> this might be a separate patch --------------mEoP4svZRf745A0JXeMW5nF4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 09/02/2024 12:40, Loftus, Ciara wrote:
Hi Maryam,

How do you want to continue with the patch, I think options we considered:

1. Fix 'use_cni' documentation (which we can backport to LTS) and
overload the argument for new purpose. This will enable new feature by
keeping backward compatibility. And requires new version of this patch.

2. If the 'use_cni' is completely broken in the 23.11 LTS, which means
there is no user or backward compatibility to worry about, we can merge
this patch and backport it to LTS.

3. Don't backport this fix to LTS, merge only to current release, which
means your new feature won't be available to some users as long as a few
years.


(1.) is most user friendly, but if 'use_cni' already broken in LTS we
can go with option (2.). What do you think?



btw, @Ciara, @Maryam, if (2.) is true, how we end up having a feature
('use_cni' dev_args) completely broken in an LTS release?

My understanding is that the use_cni implementation that is available in the 23.11 LTS is compatible with a particular version of the afxdp-plugins-for-kubernetes source. Maryam's change makes it compatible with the latest version. @Maryam can you confirm this?
If my understanding is correct then I think we should include the version/tag/commit-id of afxdp-plugins-for-kubernetes that the code is compatible with. Including backporting a patch to LTS to specify what version that code is comaptible with.


Yeah that's correct, the existing use_cni implementation would work with a particular version of the AF_XDP Device Plugin (with the limitation that the DPDK pod cannot request multiple interfaces from different device pools). From a deployment POV - I would consider this a broken behaviour. Non the less we can document it more explicitly.

The use_cni changes I'm making now will enable multi interface support (for a DPDK pod, keeping backward compatibility in mind). It will also still work with the older version of the AF_XDP device plugin (with the 1 interface limitation for the DPDK pod). I will document all of these in the next revision. 

In addition to the changes mentioned above, I'm also extending the AF_XDP PMD to support retrieving the xskmap FD from a pinned BPF map (A new feature in the AF_XDP Device Plugin).

All the above will be pushed in another revision of the patchset shortly (in addition to documentation changes). I'm just running tests and breaking down the patches into (hopefully) logical chunks.

And lastly there's one other issue that I'm trying to also investigate/resolve - which is the AF_XDP Device Plugin integration under AF_XDP PMD doesn't support busy polling. That's probably another feature to add. >>> this might be a separate patch

--------------mEoP4svZRf745A0JXeMW5nF4--