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 55E5DA04DB; Thu, 15 Oct 2020 11:27:51 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3B6651DD02; Thu, 15 Oct 2020 11:27:50 +0200 (CEST) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id 74F351DCFF for ; Thu, 15 Oct 2020 11:27:48 +0200 (CEST) Received: by mail-il1-f196.google.com with SMTP id j8so3351955ilk.0 for ; Thu, 15 Oct 2020 02:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=htrelz8a4BJNevGmdCcBrdPLmeR6zKliBNElicNCfPQ=; b=egWEMNwGEDoQH8mpgVwa9Ea9dXDApf6WODdZboaMKduzH0uuQp7zMiTJW/8lCn8NVY lh0karq5kJKh+s5XpzIBS0svQu46f4hWY9pCojA86uLDX0lf85ZgGBM5RVRwHX71BoY9 8rga+900GCUrG/61MiLPNXrD9J8tvQIMM6TiE2hnyAX/pcsqBK7fTZc2P6oq493wKloJ r6u5D+JeWOxpvEEmLJpDJGk1aFNURnILYHirGwVMaNNKK8V4DSTcw3WuOhr0CulJ51y1 +Bjzs7TTy6xf1OvxV3O63nri0vXhH+yNedZ6sAHoe5GNU43GnP9dW1OODei58yaPllbI ZNZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=htrelz8a4BJNevGmdCcBrdPLmeR6zKliBNElicNCfPQ=; b=OIY0ADc4/3q/SQHy+03d7FIymQijxJs76tgUifeIqSoBlpKaVicYuao9/HSC3r9Dn4 zPsfjubrheAGWgVcamNtOUfKHpAxXI2ZTRnHndOnBa8LBxgB8kh+TFc0uQh2FfuKMxRM eAK94KeOLgQ7ArI+GGwK3D6Or2uMNEPxV+UOqpRViqaCYtBuw6rVgbwqLxHWFZyBj6wh yFCTg1fbJeiwGIoSAWvTVwVYVuvkdH3nOxaBFZfCRxa1LvPMT9boOOt6J9M6lQhoOgBc 5QksNegWMRCNEqS5Uo5u3L7hmzgZRL7CWAyjPntNTLP21IpsgNj9K9KqABc7NEfdQOAy Q4ag== X-Gm-Message-State: AOAM531Pmf7t+ieOivSRW2arxJ1ogx/4/20Po3aBERUltIK2UmBS01cu +hBAmcXqhbrMbw1WH97/T8Ewo1hYA5SWZ+DAsNY= X-Google-Smtp-Source: ABdhPJyb0/irePFNmljmoFOwhQByCbQhK+jKkphAK53tyvQRN1OODErdljJq/2cGGp1TR4cwaRdUODv05eTE2s1wugA= X-Received: by 2002:a05:6e02:11b4:: with SMTP id 20mr2448253ilj.271.1602754066723; Thu, 15 Oct 2020 02:27:46 -0700 (PDT) MIME-Version: 1.0 References: <1602699122-15737-1-git-send-email-viacheslavo@nvidia.com> <1602699122-15737-2-git-send-email-viacheslavo@nvidia.com> In-Reply-To: From: Jerin Jacob Date: Thu, 15 Oct 2020 14:57:30 +0530 Message-ID: To: Slava Ovsiienko Cc: dpdk-dev , NBU-Contact-Thomas Monjalon , Stephen Hemminger , Ferruh Yigit , Olivier Matz , Maxime Coquelin , David Marchand , Andrew Rybchenko Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v6 1/6] ethdev: introduce Rx buffer split 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 Thu, Oct 15, 2020 at 1:13 PM Slava Ovsiienko wrote: > > Hi, Jerin Hi Slava, > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Wednesday, October 14, 2020 21:57 > > To: Slava Ovsiienko > > Cc: dpdk-dev ; NBU-Contact-Thomas Monjalon > > ; Stephen Hemminger > > ; Ferruh Yigit ; > > Olivier Matz ; Maxime Coquelin > > ; David Marchand > > ; Andrew Rybchenko > > > > Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split > > > > On Wed, Oct 14, 2020 at 11:42 PM Viacheslav Ovsiienko > > wrote: > > > > > > The DPDK datapath in the transmit direction is very flexible. > > > An application can build the multi-segment packet and manages almost > > > all data aspects - the memory pools where segments are allocated from, > > > the segment lengths, the memory attributes like external buffers, > > > registered for DMA, etc. > > > > > [..snip..] > > > > For example, let's suppose we configured the Rx queue with the > > > following segments: > > > seg0 - pool0, len0=14B, off0=2 > > > seg1 - pool1, len1=20B, off1=128B > > > seg2 - pool2, len2=20B, off2=0B > > > seg3 - pool3, len3=512B, off3=0B > > > > > > Sorry for chime in late. This API lookout looks good to me. > > But, I am wondering how the application can know the capability or "limits" of > > struct rte_eth_rxseg structure for the specific PMD. The other descriptor limit, > > it's being exposed with struct rte_eth_dev_info::rx_desc_lim; If PMD can > > support a specific pattern rather than returning the blanket error, the > > application should know the limit. > > IMO, it is better to add > > struct rte_eth_rxseg *rxsegs; > > unint16_t nb_max_rxsegs > > in rte_eth_dev_info structure to express the capablity. > > Where the en and offset can define the max offset. > > > > Thoughts? > > Moreover, there might be implied a lot of various limitations - offsets might be not supported at all or > have some requirements for alignment, the similar requirements might be applied to segment size > (say, ask for some granularity). Currently it is not obvious how to report all nuances, and it is supposed > the limitations of this kind must be documented in PMD chapter. As for mlx5 - it has no special > limitations besides common requirements to the regular segments. Reporting the limitation in the documentation will not help for the generic applications. > > One more point - the split feature might be considered as just one of possible cases of using > these segment descriptions, other features might impose other (unknown for now) limitations. > If we see some of the features of such kind or other PMDs adopts the split feature - we'll try to find > the common root and consider the way how to report it. My only concern with that approach will be ABI break again if something needs to exposed over rte_eth_dev_info(). IMO, if we featured needs to completed only when its capabilities are exposed in a programmatic manner. As of mlx5, if there not limitation then info rte_eth_dev_info::rxsegs[x].len, offset etc as UINT16_MAX so that application is aware of the state. > > With best regards, Slava >