From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BD6EC433FF for ; Wed, 14 Aug 2019 14:56:13 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 841B6206C1 for ; Wed, 14 Aug 2019 14:56:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="S3nvO2/Y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 841B6206C1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=networkplumber.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3622A1B19; Wed, 14 Aug 2019 16:56:11 +0200 (CEST) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by dpdk.org (Postfix) with ESMTP id E8C061252 for ; Wed, 14 Aug 2019 16:56:09 +0200 (CEST) Received: by mail-pg1-f178.google.com with SMTP id x15so42866606pgg.8 for ; Wed, 14 Aug 2019 07:56:09 -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=ZrW6odULOa4v8LzsY75+NHSjKQkw1qFITB42CJ94/5s=; b=S3nvO2/YdWmKFkNxchgqPRMJNBHAfUQq/H0OY99HiyjNZfb18nqk8YMBPfIC4C8OeI CzNEk7OUIz7XrBN8rpD+KXYF4YVHs+pDh+8vCl5lg59EQYOKuhh/WyCtpUPT8Abq83LG XWwV+Z64Ge9vqv9FXJ1pq7RTz/ACOF4koPSof5XF62PXgKjnaqqoNzj5W8LlO3fAjUSz pbpLRrJKvo6Wp/5upIrD+AXlGTR9hZWZg2vEx7/W9G2QYtxJaQC+P9nymB+23RdR9YpH 1w0/FPV+QitmF/0OThMNiNHG359HPfxRHXupl91ShGhlIQZukRLt8EPDJUUlquhcFTFv VeSw== 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=ZrW6odULOa4v8LzsY75+NHSjKQkw1qFITB42CJ94/5s=; b=ZZ9VjzVy2bvU7FF5J7elGq4Rathrmkbum8DHikl3eDAgYEc/UFikFoyx792Av1gXns XM3y9ZKdLMrcE7V5Adwq0g1ZfagbZhw7WfWbGd1Ig61SVpYX3eNEp9JWFqqC0jeCpWNc Doife2hfQa0OR5CtQ7QeWPa1PzcYLZoX0eitMXOk2758L2gL1dzGB7sbcFM1aJEqukdv zgGpgmo2YbPkHnrhhv99LgqFS0xzmoX0lyXO0LsVId33HYLoFfIywSbXx1pVeoFn111T ObkABzjZLl5oFXWZp8UO4hnbyJsF9BxDYd+KpOngEtHqCcZUP1iRjG8hYMy9kXq8JoTK o/NA== X-Gm-Message-State: APjAAAU/LvF/Ezm8GYtzsRhUokyj4Lx30HftyqdE0XjfHECDwfZ3UEjZ atsL1nmU9gPRuYNjrdjYkHJbUA== X-Google-Smtp-Source: APXvYqzTPHg7dwVeH5GtzVfEGL5QzhDRMVWS+fH3OgQv/QAhd/SFVy1sNc5CmQZaQv6ztTlqL1PM/A== X-Received: by 2002:a62:5487:: with SMTP id i129mr322343pfb.69.1565794568790; Wed, 14 Aug 2019 07:56:08 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id h70sm107614757pgc.36.2019.08.14.07.56.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Aug 2019 07:56:08 -0700 (PDT) Date: Wed, 14 Aug 2019 07:56:00 -0700 From: Stephen Hemminger To: Ori Kam Cc: Thomas Monjalon , "ferruh.yigit@intel.com" , "arybchenko@solarflare.com" , Shahaf Shuler , Slava Ovsiienko , Alex Rosenbaum , "dev@dpdk.org" Message-ID: <20190814075600.1d9bc493@hermes.lan> In-Reply-To: References: <1565703468-55617-1-git-send-email-orika@mellanox.com> <20190813084619.6b78a7b9@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] ethdev: support hairpin queue 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 Wed, 14 Aug 2019 06:05:13 +0000 Ori Kam wrote: > > -----Original Message----- > > From: Ori Kam > > Sent: Wednesday, August 14, 2019 8:36 AM > > To: Stephen Hemminger > > Cc: Thomas Monjalon ; ferruh.yigit@intel.com; > > arybchenko@solarflare.com; Shahaf Shuler ; Slava > > Ovsiienko ; Alex Rosenbaum > > ; dev@dpdk.org > > Subject: RE: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > Hi Stephen, > > > > > -----Original Message----- > > > From: Stephen Hemminger > > > Sent: Tuesday, August 13, 2019 6:46 PM > > > To: Ori Kam > > > Cc: Thomas Monjalon ; ferruh.yigit@intel.com; > > > arybchenko@solarflare.com; Shahaf Shuler ; Slava > > > Ovsiienko ; Alex Rosenbaum > > > ; dev@dpdk.org > > > Subject: Re: [dpdk-dev] [RFC] ethdev: support hairpin queue > > > > > > On Tue, 13 Aug 2019 13:37:48 +0000 > > > Ori Kam wrote: > > > > > > > This RFC replaces RFC[1]. > > > > > > > > The hairpin feature (different name can be forward) acts as "bump on the > > > wire", > > > > meaning that a packet that is received from the wire can be modified using > > > > offloaded action and then sent back to the wire without application > > > intervention > > > > which save CPU cycles. > > > > > > > > The hairpin is the inverse function of loopback in which application > > > > sends a packet then it is received again by the > > > > application without being sent to the wire. > > > > > > > > The hairpin can be used by a number of different NVF, for example load > > > > balancer, gateway and so on. > > > > > > > > As can be seen from the hairpin description, hairpin is basically RX queue > > > > connected to TX queue. > > > > > > > > During the design phase I was thinking of two ways to implement this > > > > feature the first one is adding a new rte flow action. and the second > > > > one is create a special kind of queue. > > > > > > > > > Life would be easier for users if the hairpin was an attribute > > > of queue configuration, not a separate API call. > > > > I was thinking about it. the reason that I split the functions is that they use > > different > > parameters sets. For example the hairpin queue doesn't need memory region > > while it does need > > the hairpin configuration. So in each case hairpin queue / normal queue there > > will be > > parameters that are not in use. I think this is less preferred. What do you think? > > > > Forgot in my last mail two more reasons I had for this for this: > 1. changing to existing function will break API, and will force all applications to update date. > 2. 2 API are easier to document and explain. > 3. the reason stated above that there will be unused parameters in each call. New API's are like system calls, they create longer term support overhead. It would be good if there was support for this on multiple NIC types.