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 AB774A00E6 for ; Tue, 6 Aug 2019 01:22:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 165241B9A8; Tue, 6 Aug 2019 01:22:57 +0200 (CEST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by dpdk.org (Postfix) with ESMTP id F3C3A1B997 for ; Tue, 6 Aug 2019 01:22:55 +0200 (CEST) Received: by mail-lf1-f54.google.com with SMTP id b29so52143533lfq.1 for ; Mon, 05 Aug 2019 16:22:55 -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=KSYYlhJ7wjPYniU85BSX0IyAlNcS52xR86erj18yGRg=; b=DnolFRGWhhWDoB0hMcgvvegm0dElVGmwu34sGV9FOdK8D0AmatuHgt8HfNdA+qNKjy X6OBTDFTOolp1joNyzxAG4bAs92tmyg9US1bpqy4hbF0AXoAgPu4sGxndL1QUfYKHqel cCt8FtnAuuWqrgL7T1B+GiXdQN2xWZS8L88k6gKZNp0s330Vf69HGodITFqxChSAy5CY gr1Usg2/Ymj4KJ1vd5SilxAgr/PxqzNBbqLUrpqBo8tWBBn9Y6cCJkQWl6X00zHXZW3G hDEod1xxe6roFsVb0+jGju/rBCc6UfFxSDyHQlx2HAbKcPJBo3mYyxhDp/QMyloA6mhI KqrA== 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=KSYYlhJ7wjPYniU85BSX0IyAlNcS52xR86erj18yGRg=; b=ikmh64iS/lmKIn8UPCTCSaAllQVZuWKkNf31EjOoViKjGAN1FULyTbDJfw9FYHRdPW Pw7ZbzSWCoSeMX1iAxPRyP3XnfZ5wyPYGTUNKRcwUEHxEBqS/2JbatSjfYjezs/XicSp /AED2H1Rgm0qf0FDPA2d0dN6BI1aaFPYq/XDxULcwny6R41LUCsWBmJzY+AaSCbb6n2g /YzNLZIWReKXI1D96UoM8j7+8ibOLXh0ADN2tiNa2GkBQByWebS0o3vZwwaLIu3F8p3o CJ7cpLjSkFKn3Jdvp03hwb9y4cc7H0k0sbz5lfHMu9nerr+nZIDr0QFErpUfImI9ypXy 8y0A== X-Gm-Message-State: APjAAAV+URAPVdWTuXpJPwZRPayS8CS9uZSBD2vc5rdREUnhyGesGsyJ QUT/+pwH4VcvY/nXoMP9YWK3avJdxu2uRzhNlde0dA== X-Google-Smtp-Source: APXvYqzWAwbCB2qB4t8GDzPpyTLP4Hr7U4RsrQLDW8KczVDkhu95yAAHt8lrTbGjREqnricfgmKEDs2wZNzrOZHGuP8= X-Received: by 2002:a05:6512:288:: with SMTP id j8mr116333lfp.181.1565047375409; Mon, 05 Aug 2019 16:22:55 -0700 (PDT) MIME-Version: 1.0 References: <20190805081110.GI4512@6wind.com> In-Reply-To: <20190805081110.GI4512@6wind.com> From: Arvind Narayanan Date: Mon, 5 Aug 2019 18:22:43 -0500 Message-ID: To: Adrien Mazarguil Cc: users Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-users] rte_flow multiple queues in same rule's action set X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" On Mon, Aug 5, 2019 at 3:11 AM Adrien Mazarguil wrote: > > On Fri, Aug 02, 2019 at 06:01:49PM -0500, Arvind Narayanan wrote: > > Hi, > > > > In rte_flow docs, there is an example (Table 11.28) where the action > > set consists of 4 actions: > > > > 1. queue(index=5) > > 2. VOID > > 3. queue(index=3) > > 4. END > > The docs further say such a rule effectively duplicates the traffic to > > both queue 3 and 5. Does this mean "two different mbufs" exist for the > > same incoming packet, or does it mean it only duplicates the mbuf > > references? > > > > Any clarification is appreciated. > > Beware I'm not aware of any driver properly supporting this at the moment, > so specifying QUEUE twice should usually result in an error, but I think > some drivers don't quite expect it and will silently ignore one of them > (that's a bug). > > In any case you're right, it's unspecified and we should fix that. > There are 3 options: > > 1. Separate mbufs are returned. That was the original unwritten assumption > (see below). > > 2. Separate mbufs are returned, but one of them is a clone so they actually > share data and RTE_MBUF_CLONED() returns true for one of them. > > 3. The same mbuf pointer is returned, in which case at the very least, mbuf > refcount should be 2 not to break rte_pktmbuf_free(). > > In practice drivers can normally not return the same mbuf from two distinct > Rx queues at the same time since Rx mbufs are allocated independently for > each Rx queue. Mbufs are preallocated during setup and replaced while doing > Rx, right before returning them to the application to avoid starvation. > > I do not think DPDK applications are ready for 2 and 3 yet. Also due to the > above, doing so would require extra work on the PMD side. > Makes perfect sense. Thanks Adrien! Arvind > -- > Adrien Mazarguil > 6WIND