From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 02162A04AB; Sun, 30 Aug 2020 20:27:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 72CB52B93; Sun, 30 Aug 2020 20:27:10 +0200 (CEST) Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by dpdk.org (Postfix) with ESMTP id 4C709CF3 for ; Sun, 30 Aug 2020 20:27:08 +0200 (CEST) Received: by mail-pj1-f67.google.com with SMTP id o16so537640pjr.2 for ; Sun, 30 Aug 2020 11:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=c9aFTc8kK+TuWOZMW9oB14/+r5clMtMDzXKczkGh1jE=; b=GbHwLB50JqgRYcmqMniO9T2ucfytGDjaUCjgi9UWdIq7u+J55BRtCa1rzu4GTu5nWH 3bu9yxxujM/TLzVUVXYfpwm2+U1OqTbAuRb5axixKFNgbtBopBaURBBPxwMu2gaIcXcw /3C5/KA0qCbrU6DfuXwY0AOVNh595IybXSIE1dSJm5cKe9o/sgcM39KMDdE7DccLOWtu A0dIwhJETNyHO2JEALFxpoyAEvu5WrnJ2kP1zlX1utmAxqHq7jnlJej5wm9yxs/rzwWq RmBIsgBPc5R89m7Ry7lZWToAt4i6SE67Ml3hqpdhduOX8j7C6cWUIjo48XCtFMVBekwk jqGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=c9aFTc8kK+TuWOZMW9oB14/+r5clMtMDzXKczkGh1jE=; b=Nym/cDH+Xozs3+CiTzyIsYqwFsZCA2k3+WgIunlQtEAJVNeY8Dt3m/UHxz/2abQon9 FTjjdQ46mA8AUWCME7BX6a6HIRzmY0nwlofJH2+c6hy9xqSLOFIAgMEUtnaNPBhAA1JU AF4kPGRYBBuriC3JLDD0X00GXMktVgQLePLegXWsMjECMgac//npX36doB9+sRV/Q9tB 37RrYt0/Ysi1nbBxEo4LCDuhCsHlEpqWeYU9X9Z2U21NGnKk121+ga/tQkZ+9AcF/s9J 7B+s9Mcyg28u+ZWeKai8Me5pjxS2ozBWKkmFYfACVznZ+XVJiwPmhdyU4201uj2sJrWI GhWw== X-Gm-Message-State: AOAM533QK68GkLAwLWUIC9Dm/v/r73p/XFDSnTcGBbM3fN9uthWB6ORD FPX+sW5neIzLx/PtJpeVCVijaw== X-Google-Smtp-Source: ABdhPJzGl2+ZFQL/goRi/o7VNsghSxKtzoyuqCw5kKRwcv3oe957hpGKKmZgbMBCTppgrXz+uhxHWg== X-Received: by 2002:a17:902:b205:: with SMTP id t5mr6135772plr.7.1598812027239; Sun, 30 Aug 2020 11:27:07 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id z26sm5415099pfa.55.2020.08.30.11.27.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Aug 2020 11:27:06 -0700 (PDT) Date: Sun, 30 Aug 2020 11:26:58 -0700 From: Stephen Hemminger To: Andrew Rybchenko Cc: Slava Ovsiienko , "dev@dpdk.org" , Matan Azrad , Raslan Darawsheh , Thomas Monjalon , "ferruh.yigit@intel.com" , "jerinjacobk@gmail.com" , "ajit.khaparde@broadcom.com" , "maxime.coquelin@redhat.com" , "olivier.matz@6wind.com" , "david.marchand@redhat.com" Message-ID: <20200830112658.0d5f532e@hermes.lan> In-Reply-To: References: <79886244-1390-6c99-287d-1d868bb4090a@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] doc: announce changes to ethdev rxconf structure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sun, 30 Aug 2020 15:58:57 +0300 Andrew Rybchenko wrote: > >>>>> > >>>>> The non-zero value of rx_split_num field configures the receiving > >>>>> queue to split ingress packets into multiple segments to the mbufs > >>>>> allocated from various memory pools according to the specified > >>>>> lengths. The zero value of rx_split_num field provides the backward > >>>>> compatibility and queue should be configured in a regular way (with > >>>>> single/multiple mbufs of the same data buffer length allocated from > >>>>> the single memory pool). =20 > >>>> > >>>> From the above description it is not 100% clear how it will coexist = with: > >>>> =C2=A0- existing mb_pool argument of the rte_eth_rx_queue_setup() > >>>> =C2=A0- DEV_RX_OFFLOAD_SCATTER =20 > >>> > >>> DEV_RX_OFFLOAD_SCATTER flag is required to be reported and configured > >>> for the new feature to indicate the application is prepared for the > >>> multisegment packets. =20 > >> > >> I hope it will be mentioned in the feature documentation in the future= , but > >> I'm not 100% sure that it is required. See below. =20 > > I suppose there is the hierarchy: > > - applications configures DEV_RX_OFFLOAD_SCATTER on the port and tells = in this way: > > "Hey, driver, I'm ready to handle multi-segment packets". Readiness in = general. > > - application configures BUFFER_SPLIT and tells PMD _HOW_ it wants to s= plit, in particular way: > > "Hey, driver, please, drop ten bytes here, here and here, and the rest = - over there" =20 >=20 > My idea is to keep SCATTER and BUFFER_SPLIT independent. > SCATTER is a possibility to make multi-segment packets getting > mbufs from main rxq mempool as many as required. > BUFFER_SPLIT is support of many mempools and splitting > received packets as specified. No. Once again, drivers should take anything from application and rely on using logic to choose best path. Modern CPU's have good branch predictors, and ma= king the developer do that work is counter productive.