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 12ABBA0613 for ; Thu, 26 Sep 2019 14:32:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C7A5C2C39; Thu, 26 Sep 2019 14:32:34 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 193431DBD for ; Thu, 26 Sep 2019 14:32:33 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 2EBCBA8007D; Thu, 26 Sep 2019 12:32:31 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 26 Sep 2019 13:32:22 +0100 To: Ori Kam CC: , , , , , , , References: <1569479349-36962-1-git-send-email-orika@mellanox.com> From: Andrew Rybchenko Message-ID: Date: Thu, 26 Sep 2019 15:32:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1569479349-36962-1-git-send-email-orika@mellanox.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24934.003 X-TM-AS-Result: No-14.419800-8.000000-10 X-TMASE-MatchedRID: oHOSwQSJZWjmLzc6AOD8DfHkpkyUphL9APiR4btCEeYy2ckJNvUX+E/p IBlKc8DIXbLhfvpbIkiwYL2Bevsfp3I5WT4U/MvXKnjj4PzuQYdKRaXN2yYjHg34XnXcobKrSEn +1+RWwv5bdScq6YVMbkNcQo2KyD3zRddrw/oS57c3X0+M8lqGUgKflB9+9kWV9WYwTxriQ0pj6y 1eE6mExWLdoKqv7Dxm8ZlvyFl7jChADSr/cNEBX8nUT+eskUQPwZy9wGhpvaPHN9tnHHgXhClF0 XBLJ2PqGIfsX2xHdgsn/ojlvWnecY79EoC1T2UZwtE16arXsSIPSd3sON/LSaJprKmdp8pPCT2o g8mlUDvB7KLs+bfPKRUnzyzzSIpWBnMOXay0wq5JUdgxNDUXWkYj0zDHPzJpU20Pec0W1lbtqcl VmBztDtfXz/M9XJaWs/2j1FYrEUyKtzzisoybeZ4CIKY/Hg3AtOt1ofVlaoLUHQeTVDUrItRnEQ CUU+jzjoczmuoPCq18ls4OS84wuzm3exCZAXyqqsuAXGPzB2BoIqscKJ80QdoANojgDJ/2 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--14.419800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24934.003 X-MDID: 1569501152-KdFcs6U-w9x4 Subject: Re: [dpdk-dev] [PATCH 00/13] add hairpin feature 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 9/26/19 9:28 AM, Ori Kam wrote: > This patch set implements the hairpin feature. > The hairpin feature was introduced in 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. Is it just a pipe or RTE flow API rules required? If it is just a pipe, what about transformations which could be useful in this case (encaps/decaps, NAT etc)? How to achieve it? If it is not a pipe and flow API rules are required, why is peer information required? > 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. > > The advantages of using the queue approch: > 1. More control for the application. queue depth (the memory size that > should be used). But it inherits many parameters which are not really applicable to hairpin queues. If all parameters are applicable, it should be explained in the context of the hairpin queues. > 2. Enable QoS. QoS is normaly a parametr of queue, so in this approch it > will be easy to integrate with such system. Could you elaborate it. > 3. Native integression with the rte flow API. Just setting the target > queue/rss to hairpin queue, will result that the traffic will be routed > to the hairpin queue. It sounds like queues are not required for flow API at all. If the goal is to send traffic outside to specified physical port, just specify it as an flow API action. That's it. > 4. Enable queue offloading. Which offloads are applicable to hairpin queues? > Each hairpin Rxq can be connected Txq / number of Txqs which can belong to a > different ports assuming the PMD supports it. The same goes the other > way each hairpin Txq can be connected to one or more Rxqs. > This is the reason that both the Txq setup and Rxq setup are getting the > hairpin configuration structure. > > From PMD prespctive the number of Rxq/Txq is the total of standard > queues + hairpin queues. > > To configure hairpin queue the user should call > rte_eth_rx_hairpin_queue_setup / rte_eth_tx_hairpin_queue_setup insteed > of the normal queue setup functions. > > The hairpin queues are not part of the normal RSS functiosn. > > To use the queues the user simply create a flow that points to RSS/queue > actions that are hairpin queues. > The reason for selecting 2 new functions for hairpin queue setup are: > 1. avoid API break. > 2. avoid extra and unused parameters. > > > This series must be applied after series[2] > > [1] https://inbox.dpdk.org/dev/1565703468-55617-1-git-send-email-orika@mellanox.com/ > [2] https://inbox.dpdk.org/dev/1569398015-6027-1-git-send-email-viacheslavo@mellanox.com/ [snip]