From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 8EC0EA0679 for ; Tue, 30 Apr 2019 22:08:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 066B43257; Tue, 30 Apr 2019 22:08:40 +0200 (CEST) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by dpdk.org (Postfix) with ESMTP id 07AFD2C23 for ; Tue, 30 Apr 2019 22:08:38 +0200 (CEST) Received: by mail-ot1-f43.google.com with SMTP id 77so6952875otu.13 for ; Tue, 30 Apr 2019 13:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ves.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uGKIpRBIoxUYkYNTrNSzYhlxqoVAf7lEo9qfVHwmCNA=; b=FB3hvQjsh3XfOcjbDB2vXbs0l5/+tcBEHjpO0ke9tQwThjYCk4U0ftPDqUZ1EHiaat 9qvmyglU9NzLinYuCMDR2ykd8iDwaxWdqc+pwMjoP4mAHB3IOUB2qSpc3s81K4wa1kJU lshcIQMMjBV36GaZkg7SlnUJDJHj+uH/z5JFyhWlL9P/SMxh4E/A1YuM7GgR4npWrvpe ihD/bY3tBt+yGxxFMKEaHbqILzKzDFHs9i41feGcFT6eVo020p8kd61xEUjvesPrT5eT md9M6fkDpdMll5mQ/31XVBbg7kPJEDjpVXV7UUMyKpW1+eqG8ikhsZuLHmWsipqms5yR IEUQ== 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=uGKIpRBIoxUYkYNTrNSzYhlxqoVAf7lEo9qfVHwmCNA=; b=lbmgJ4guULta66kqi8lfY0QOzOABFkaegEfNykZnbFesH4E0CoxBRGclItGYgPCi83 jH6q3b8Dg+FyWczu4uwlTbGUjfBH253D/TTElPiW/4X9D+IvRu8FGEHLkLtcZXj83hok /Md3wmXW7kGHIPKNKmw1HZfyXgy7XnBIYGDPJ+AeoOj8B6AwduEVeikUrAAU79armQ1U VYiwdRXcbPawBbTLaoxOTgQSV3fvD08x5jq8LEo2Fit6aGgrs3XaoJkPxnGUxaRBSPI/ nCXIRIz0r8COq0V5a+CG5fK+I9sXSWB2RtwVlZ1V4dgQLKNsoWhCEXdtFR10sls9FSpL 73Dg== X-Gm-Message-State: APjAAAU897GaGOv6Jc/M9mPDDxmhUVFul64Czn+7yrUYyLG2m7+PZLhP issnMXM/5SD7OzhJF+Go5SOnm54nolaD/FMShG5ycA== X-Google-Smtp-Source: APXvYqygXUHMh2N9qJG1alY/bsqh2BIW/nWNXz+pEPNP9TnpiiX35QR8Ct1qIP6pACFDzReh//MH5bCS/TpYoGttiEE= X-Received: by 2002:a9d:ecd:: with SMTP id 71mr39502367otj.127.1556654917344; Tue, 30 Apr 2019 13:08:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Avi Cohen Date: Tue, 30 Apr 2019 23:08:25 +0300 Message-ID: To: "Van Haaren, Harry" Cc: Sara Gittlin , users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] HW cache utilisation w OVS-DPDK 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" Thank you Harry very much for your detailed answer. I think that ovs with Data plane is a kernel module (i.e. not ovs dpdk) the flow table is somehow always in the cache, hence there is an eviction function in user space that is sending commands to the kernel to delete non active flows in order to make place in this expensive cache memory. But i dont know how it is w ovs-dpdk. I know that generaly caches mem are transprant to sw, but w ovs kernel module the flow table is always stored in cache. Thanks again Harry -Sara =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=92=D7=B3, 30 = =D7=91=D7=90=D7=A4=D7=A8=D7=B3 2019, 21:33, =D7=9E=D7=90=D7=AA Van Haaren, = Harry =E2=80=8F< harry.van.haaren@intel.com>: > > -----Original Message----- > > From: users [mailto:users-bounces@dpdk.org] On Behalf Of Sara Gittlin > > Sent: Tuesday, April 30, 2019 6:15 PM > > To: users@dpdk.org > > Subject: [dpdk-users] HW cache utilisation w OVS-DPDK > > > > Hello All > > Hi Sara, > > > It is a naive and maybe a stupid question , but do we use HW cache L1/L= 2 > > etc with OVS-DPDK? > > The hardware CPU caches (L1, L2 and LLC) are transparent to software. > > Another way to say that is that When writing code, the software doesn't > have to explicitly use L1 or L2, the memory being used (from libc malloc(= ) > or stack memory) > is cached by the CPU without any software involvement. > > In short, software uses L1/L2/etc without "knowing" it as such... > > However, just because we (as C software developers) cannot directly acces= s > cache, > does not mean that we should ignore it! In particular designing > cache-conscious > data-structures can have a *huge* impact on runtime performance. > > I recommend some of the CPP Con talks on software performance, particular= ly > the one titled "Efficiency with Algorithms, Performance with Data > Structures". > > > > for example where the flow-table is stored ? in HW-cache or in RAM? > > This is a good question - and the answer is like so many engineering > questions - it depends :) > > If the part of the flow-table has been recently accessed, it is likely to > be in the HW-cache. > If the flow-table has been initialized, but not used recently it is likel= y > to be in ordinary RAM. > > From a performance point of view, this is quite interesting, as certain > flow-table accesses > are expected to be cheap (in cache) while others might take longer (RAM). > > > > Thank you > > -Sara > > Hope that helps! Regards, -Harry >