From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8F2E645B50; Wed, 16 Oct 2024 11:38:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1620A40264; Wed, 16 Oct 2024 11:38:50 +0200 (CEST) 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 8BCEA400D6 for <dev@dpdk.org>; Wed, 16 Oct 2024 11:38:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729071529; 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=IOQC4mX7XyUahocl28Z9LUh3lHTMIXJpwg1zrGVtOkU=; b=FVyzUxayO42MR8IyEyldv516Yi5t9HPPWQ9AFtiVCxcc+9yCcnQqgzC6zLPqOJz3CVdc8+ /HtQkzW6JSgZ9d3LnRfMDQdL4HmMsONCmTygfwYQHtk5I0T4NnsOdVOpfihHhF+QMf2lrJ 2XmB3blRCxaUW4xx0fmRYkzRhPwbXoQ= 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-483-74uygk7tM7WhebINJxXxhQ-1; Wed, 16 Oct 2024 05:38:48 -0400 X-MC-Unique: 74uygk7tM7WhebINJxXxhQ-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-43151a9ea95so2099075e9.1 for <dev@dpdk.org>; Wed, 16 Oct 2024 02:38:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729071527; x=1729676327; h=in-reply-to:references:user-agent:cc:subject:to:from:message-id :date:content-transfer-encoding:mime-version:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=IOQC4mX7XyUahocl28Z9LUh3lHTMIXJpwg1zrGVtOkU=; b=R+n83U95VqsYGCQ9Flhhq4Dd6L5+h+xENHDf2HGbbUe8x/Jn8GZFsoh3A/zX0Ms8LM yaQG32MNKJZilVVsX60qZhLFEH3YUl8CvxXeN4gP02RSQ7+5/WJ5tytAGrT3a+pu8FYp BCzK26UwuOlzLN8Z19ClzKMBVK1ekFggaJhJbZYzP8HJQ4RAlziNGSzLe3Mg+oy00O9V xn7MZ0vYJqtHcqk46bYhnr8uFq070bnj303SVisFq6EXAxQEF67AGU1v1jokV4MxZvAQ bWVqYKp6g1iMkZRapJ2jCiYDiHfegy2GTdoTT9WEIz1pDxl8cXRGFwcGOBrsNcwVYWCK SmCQ== X-Forwarded-Encrypted: i=1; AJvYcCUr+0/ngAJgYlg2O9YkUQhRxGMKve6+Sc0ljGKc3FYFljoZBWHAHpXUp3cGPVxOIreF+x0=@dpdk.org X-Gm-Message-State: AOJu0YxfpyruZi1G75xWjy+u8SqpfXxpsx6cWkBcHaPWpnmU3LKg83Y9 ApTngIe1JJopgjDG0WlWaHK9iLHggbWIdagPAJbUjIcEhy5OdYDFmDC975OKs7idXME1OW+TnYs OXCoFzNWegjSWnbH+JPR41cxqQtTLW3qYFeaCDMnQ X-Received: by 2002:a5d:47aa:0:b0:374:b9ca:f1e8 with SMTP id ffacd0b85a97d-37d862fe835mr3337979f8f.20.1729071525438; Wed, 16 Oct 2024 02:38:45 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGGvtLJ/s+0lpFCjOFhcrVPLAiUu9zKawEbinTGsKXytUQcywwiHgXLGkWFx48avDQpjtI9fQ== X-Received: by 2002:a5d:47aa:0:b0:374:b9ca:f1e8 with SMTP id ffacd0b85a97d-37d862fe835mr3337961f8f.20.1729071525028; Wed, 16 Oct 2024 02:38:45 -0700 (PDT) Received: from localhost (2a01cb00025433006239e1f47a0b2371.ipv6.abo.wanadoo.fr. [2a01:cb00:254:3300:6239:e1f4:7a0b:2371]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4313f6b1e42sm43673165e9.35.2024.10.16.02.38.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Oct 2024 02:38:44 -0700 (PDT) Mime-Version: 1.0 Date: Wed, 16 Oct 2024 11:38:43 +0200 Message-Id: <D4X4P8CDPZ5M.1WRRVPNRNKCHR@redhat.com> From: "Robin Jarry" <rjarry@redhat.com> To: "David Marchand" <david.marchand@redhat.com>, "Nitin Saxena" <nsaxena@marvell.com> Subject: Re: [EXTERNAL] Re: [RFC PATCH 0/3] add feature arc in rte_graph Cc: "Jerin Jacob" <jerinj@marvell.com>, "Kiran Kumar Kokkilagadda" <kirankumark@marvell.com>, "Nithin Kumar Dabilpuram" <ndabilpuram@marvell.com>, "Zhirun Yan" <yanzhirun_163@163.com>, "dev@dpdk.org" <dev@dpdk.org>, "Nitin Saxena" <nsaxena16@gmail.com>, "Christophe Fontaine" <cfontain@redhat.com> User-Agent: aerc/0.18.2-81-g43ce621f36dd References: <20240907073115.1531070-1-nsaxena@marvell.com> <CAJFAV8zRkre6OhfcXrhEK8sCzZ7BB9q-foSXeJ_2c_xqcAq2mw@mail.gmail.com> <SJ0PR18MB511158FD7D8D0263533CAEDBB6442@SJ0PR18MB5111.namprd18.prod.outlook.com> <CAJFAV8wmEOu8e-2dTojYoZTb2SRjUitikGvi9tVMuuq-933Ejg@mail.gmail.com> In-Reply-To: <CAJFAV8wmEOu8e-2dTojYoZTb2SRjUitikGvi9tVMuuq-933Ejg@mail.gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; format=Flowed X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Hi folks, David Marchand, Oct 16, 2024 at 11:24: > On Mon, Oct 14, 2024 at 1:12=E2=80=AFPM Nitin Saxena <nsaxena@marvell.com= > wrote: >> I had pushed non RFC patch series before -rc1 date (11th oct). >> We have an ABI change in this patch series https://patches.dpdk.org/proj= ect/dpdk/patch/20241010133111.2764712-3-nsaxena@marvell.com/ >> Could you help merge this patch series in rc2 otherwise it has to wait f= or next LTS > > Just read through the series, I am not confident with this addition. > It requires a lot of changes in the node code for supporting it, where > it should be something handled in/facilitated by the graph library > itself. As far as I can tell, it will be very complicated (if not impossible) to=20 determine in a generic manner whether a packet must be steered towards=20 a sub tree or not. The decision *must* come from the originating node in=20 some way or another. > I did not read much from Robin or Christophe who have been writing > more node code than me. > I would prefer their opinion before going forward. This series is indeed very dense. I like the concept of having=20 extensible sub trees in the graph but it feels like the implementation=20 is more complex than it should be. Lacking of another solution, we went for a naive approach in grout.=20 Basically, some nodes have undefined next nodes which are extended using=20 a dedicated API. https://github.com/DPDK/grout/blob/v0.2/modules/infra/datapath/eth_input.c#= L23-L31 This API can be used by other nodes to attach themselves to these=20 extensible nodes: https://github.com/DPDK/grout/blob/v0.2/modules/ip/datapath/arp_input.c#L14= 3 https://github.com/DPDK/grout/blob/v0.2/modules/ip/datapath/ip_input.c#L124 https://github.com/DPDK/grout/blob/v0.2/modules/ip6/datapath/ip6_input.c#L1= 22 After which, the extensible nodes can steer the packets towards the=20 correct downstream edge based on the dedicated classifier field: https://github.com/DPDK/grout/blob/v0.2/modules/infra/datapath/eth_input.c#= L79 Obviously, this does not natively support a per-interface sub tree=20 traversal, but it can be done in the originating node based on packet=20 private context data. This raises a more important question: how can we standardize the way=20 private application data is passed from node to node? And how could we=20 enforce this declaratively in the node register API? Do you think we could find some middle ground that would not require=20 such extensive changes? Cheers, Robin