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 5FF20A04B1; Mon, 5 Oct 2020 18:35:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B4FB34C98; Mon, 5 Oct 2020 18:35:38 +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 74081322C for ; Mon, 5 Oct 2020 18:35:36 +0200 (CEST) Received: by mail-il1-f196.google.com with SMTP id o18so8393552ilg.0 for ; Mon, 05 Oct 2020 09:35:36 -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=dx4g9TZl0deizEBsr5tDXfJfOW2LzAhJKP31D4pFL0o=; b=TucXkBJiKmA8R90bNNoG0fluGEqfGaFrvWnwChpXJvyplspDHacSU5QXY/lK6aqkhp y7We2unNimag5HNYadVNzFc/xPl8SH0oG8X4zBpZCayeypu398Q60WgBBEgOVmr1aZBE xRqFjl/ZooDyoLkDoqyHvb1Wh3QxvpNjSApnAyNdEm7jO4aLtUw9vUJbwIzIQ25MqN+9 qrRxyBkWbT84zzLsn3x59A/BnnKEvYgpjPEwNN7S6mfNsrlgzEk7m207cFwq6QBgPR/C yM9ecyqhddPVgh7Quwc3d0a7V38El1nbBTyglCHcjTSxa6LGINLQn198foBQ2Nnz4uN5 OC+Q== 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=dx4g9TZl0deizEBsr5tDXfJfOW2LzAhJKP31D4pFL0o=; b=Bz09Nb3MeaUVwGhyQ1RiefbqD1buoaLqgnhXulpbXDRzjk/q5EqhFtDQ65zeaBqWDz zYvyssSxJ6PJnNZRgC0uY16Q6MTsF+9o3GEi/ArcktGoRpiNgIkDC6DhP9jjIZHt09NP cipfQhqIqxYov8YjPjfiAMsC+/XdQLYY/6/muzZGm/G5Mw3F8Sf48WzkW88AKQNuLK6B zczkw20sJmgxoYa10Bwwy8orTqMUzbVthzw0DbD2xr1nLztGJT6wYecnxTvb37UEQSWN 1Ebp8jWcP2gweTtTqy6174Pn+DEXMmqXFeNBZzgToSZug5if91jOmTCdA/IGK8rTUQ2t +Dcw== X-Gm-Message-State: AOAM533pdZW0cXqEo/4py9aIKJKnrGG4b5VrKkz5yPZgj+GyU9wU1Eh9 T7V+pyY97OBS76m8J6q+n1+oXZGcPfks8gt9fOk= X-Google-Smtp-Source: ABdhPJwAxSlSia+HA/XN77r+cLXF3YHKUoMS+0fbj6KattUlka12R850sbsXSTtOmslq9LLAZrWfNEvAbGLoEbMTi9c= X-Received: by 2002:a92:c00c:: with SMTP id q12mr173763ild.294.1601915734740; Mon, 05 Oct 2020 09:35:34 -0700 (PDT) MIME-Version: 1.0 References: <20200908105211.10066-1-radu.nicolau@intel.com> <46118f3466274596a663d7d44abb680a@intel.com> <20200925102805.GD923@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: From: Jerin Jacob Date: Mon, 5 Oct 2020 22:05:18 +0530 Message-ID: To: "Nicolau, Radu" Cc: Honnappa Nagarahalli , Bruce Richardson , "Ananyev, Konstantin" , "Van Haaren, Harry" , "dev@dpdk.org" , "jerinj@marvell.com" , nd Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v1] event/sw: performance improvements 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 Tue, Sep 29, 2020 at 2:32 PM Nicolau, Radu wrote: > > > On 9/28/2020 5:02 PM, Honnappa Nagarahalli wrote: > > > >>> Add minimum burst throughout the scheduler pipeline and a flush counter. > >>> Replace ring API calls with local single threaded implementation where > >>> possible. > >>> > >>> Signed-off-by: Radu Nicolau mailto:radu.nicolau@intel.com > >>> > >>> Thanks for the patch, a few comments inline. > >>> > >>> Why not make these APIs part of the rte_ring library? You could further > >> optimize them by keeping the indices on the same cacheline. > >>> I'm not sure there is any need for non thread-safe rings outside this > >> particular case. > >>> [Honnappa] I think if we add the APIs, we will find the use cases. > >>> But, more than that, I understand that rte_ring structure is exposed to the > >> application. The reason for doing that is the inline functions that rte_ring > >> provides. IMO, we should still maintain modularity and should not use the > >> internals of the rte_ring structure outside of the library. > >>> +1 to that. > >>> > >>> BTW, is there any real perf benefit from such micor-optimisation? > >> I'd tend to view these as use-case specific, and I'm not sure we should clutter > >> up the ring library with yet more functions, especially since they can't be > >> mixed with the existing enqueue/dequeue functions, since they don't use > >> the head pointers. > > IMO, the ring library is pretty organized with the recent addition of HTS/RTS modes. This can be one of the modes and should allow us to use the existing functions (though additional functions are required as well). > > The other concern I have is, this implementation can be further optimized by using a single cache line for the pointers. It uses 2 cache lines just because of the layout of the rte_ring structure. > > There was a question earlier about the performance improvements of this patch? Are there any % performance improvements that can be shared? > > It is also possible to change the above functions to use the head/tail pointers from producer or the consumer cache line alone to check for perf differences. > > I don't have a % for the final improvement for this change alone, but > there was some improvement in the memory overhead measurable during > development, which very likely resulted in the whole optimization having > more headroom. > > I agree that this may be further optimized, maybe by having a local > implementation of a ring-like container instead. Have we decided on the next steps for this patch? Is the plan to supersede this patch and have different one in rte_ring subsystem, >