Message ID | 1450067576-18803-2-git-send-email-jerin.jacob@caviumnetworks.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id E66F48DAB; Mon, 14 Dec 2015 05:33:49 +0100 (CET) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0064.outbound.protection.outlook.com [65.55.169.64]) by dpdk.org (Postfix) with ESMTP id 8B58A58D4 for <dev@dpdk.org>; Mon, 14 Dec 2015 05:33:47 +0100 (CET) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@caviumnetworks.com; Received: from localhost.localdomain.localdomain (122.167.202.21) by BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) with Microsoft SMTP Server (TLS) id 15.1.337.19; Mon, 14 Dec 2015 04:33:44 +0000 From: Jerin Jacob <jerin.jacob@caviumnetworks.com> To: <dev@dpdk.org> Date: Mon, 14 Dec 2015 10:02:53 +0530 Message-ID: <1450067576-18803-2-git-send-email-jerin.jacob@caviumnetworks.com> X-Mailer: git-send-email 2.1.0 In-Reply-To: <1450067576-18803-1-git-send-email-jerin.jacob@caviumnetworks.com> References: <1449765378-29563-1-git-send-email-jerin.jacob@caviumnetworks.com> <1450067576-18803-1-git-send-email-jerin.jacob@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [122.167.202.21] X-ClientProxiedBy: MA1PR01CA0009.INDPRD01.PROD.OUTLOOK.COM (25.164.117.16) To BLUPR0701MB1714.namprd07.prod.outlook.com (25.163.85.140) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 2:hx4J2T+tRtfkc5magKck+Iy19Psm0neHrIPBrP4xmrNVUv87pyLMFMTgCTHsXe02hYhCV0N1T85NGjAJZf7Oj1Fw19fnDru52xRJfRWQ8p9LjsPJyKnffhZhOqTuv5NGXkyHTBIASsNQEQEVmLHLxQ==; 3:o24wyp1ng7dsX/EYp9hT6DKr/WSdhAQ+v5tCKPEOAqoM/QjB21d51UnJkSIUPMCXfmKr0Jyagn1hV212/VYiunt48nnCPH1H6iZ/jUvbOPU2h2OyKVUDxD16dAshLlyn; 25:G1UZxUJj1M4gjFyDWmLG8nu9tkDBpcEj1RWlNVNeGwjdE9M2vkGy1wBXTgTO1+OCJqtzec0XF1bxMBM8KGWDah6RuzsDOUxv3X+CBBpsZz/KNfsjZigEW9knUTmlXxN8rJOvgxrEuKT2dnSiGIHNctOKt/JSV1eNbHikpM0S5gXrs1rnTSRh13qAUcB4qfzABr/5vT0K4EVR1VuA80OiNm4xRD7NjYD3FeYY68d9C8609p5Fv6/uxB3d4zZ5Qh3ir/O9NLto59BclS1dnA1Nfg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 20:xTqWbcQcPJ15IA0GTbVnRv3fwAPcL8jTWsRLXsl8TxNJ9RNYF8YVoIdzBLNHja5LETePF9UkIZ8ARaqKdv5jybh2+T9Zq1lM3knIlHuAKKd55TQDj6w58bonlpHa8/l4cdH9NetbtsgoesfOEV2yxE1dTyJcKXupxPds1vlqmYntBRNPvN22cXYbitHwfZnCgVt5IuTtcsJtGgflYtuAthuPsR1SiGfI+mgJbQlu2Wp/jUUKm1cSNyC1RGKZTR62a5ZH3c7m7xqlwAVwQrBbcnNe4uk5+XK1ym4JSfrRzGh4wVA8WYCj3f2i0WTUA74S/6LD2zb+ZowBrQXGWN6tCvxX/56pcISpwARB3XUliX5YoSTx6XCiZJSH85iszxYHRxZOd36DYa6Ag+hECJ7uYF5lIyo90Xs5h13xo3WvVur6e0/VoZFsYEOntUEXQZH1TN8KGk47FtHnexfpLLUyiN4wExFph9u8j5y0R4NgDNf6+AKhx7ZFDNhrWR/uFi2miwheU4UkkrERLarC6SFnQD2PJZ9LNtqjLVt9mo1/yUgzi8QTWbysmOkv8jxrECLtp/r98XgepKiqHIiYBMnxng/6CVbq4mhn8OYOpfO9d4g= X-Microsoft-Antispam-PRVS: <BLUPR0701MB171422DCB06BBA22510580468CED0@BLUPR0701MB1714.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(236414709691187); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BLUPR0701MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 4:rl0WcCXKj0vVeEIVK/uvu7YsqzOgdTqmt3YTCBjohuldQSBcvw+GKQY5DrxuJ+K7Hy3ugMtKm/z3jpjseQRZjdrcg8mkaKx5llcDVaIr0C4ortigi5+c5jZZUEEjoFr70W/l3/nw1nMq8E1hDhpz51LF+1ObxdsMv1CHMTm2fAZCA2l2y8xSEQ7Z/Iv+970qDe8gzAlEIzs4Htgg9axEK7IRQYH29rHUdVsUvj6DV/7+xr9myR4ypnpLHeLUVsR7RNeg5uTYv+U1yCobi0WpZ4RebvRy9SsA9yvQ+VI/8lkyufqqXUrTFtsnl438FTYK0m9bUCnJGFPf8ND0Ea/xzvhf9EeLLJbCU+JYq5zSD0aQ7dN2W7T3ApU6uC0HcrqRCd5X9KvC7kkWOFR7zWCOIT7Wc0pOY8QZ3Q6/VuhEbPTnTE1hMeJzf8geLs4SO1yt X-Forefront-PRVS: 0790FB1F33 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6069001)(6009001)(189002)(199003)(48376002)(19580395003)(42186005)(77096005)(50466002)(1096002)(50226001)(66066001)(47776003)(2950100001)(5001960100002)(5004730100002)(36756003)(189998001)(101416001)(5008740100001)(4001430100002)(110136002)(6116002)(586003)(3846002)(107886002)(106356001)(105586002)(40100003)(19580405001)(33646002)(5003940100001)(87976001)(229853001)(122386002)(76176999)(81156007)(97736004)(92566002)(50986999)(86362001)(2351001)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1714; H:localhost.localdomain.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: caviumnetworks.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1714; 23:Vaisfv74LlQ2mI2RfLwwTXisJnW/E33eoX4D+sS?= =?us-ascii?Q?KqTTQzEa72acPvNTWNHG2YKJOgziReITcfdHXRYiD4bilud0S2NYZ7AibrmR?= =?us-ascii?Q?snmc6AqgAASLfdTPw3+nzHgRHS0rrp+QLRrvZB0WT0RA4oFyCiTdht7oGPUb?= =?us-ascii?Q?ocR360a445uK84dr0AxtaEux1JCEBa92INtioRU/0MHZKhCb2S775i1ei7NS?= =?us-ascii?Q?uJFEPYnel0RgjR4ieedA5fBsD8HxUKQGE6yCK5BQkmmGjxmeL88OGwTnyMTW?= =?us-ascii?Q?St1AY2IeB33MkvHOQIWy1ic25JeovonymVGxAq9xY0LEJaPCkZyPdU5v78Pb?= =?us-ascii?Q?sn27CrQrIjberPaveq0QJ1NEFJtrJAJ0RqFymXPauvG4R2aCTGSI1tIYZwsN?= =?us-ascii?Q?ealRDZPj3CChobnqcSAFKCwxU9q6aUL0AEdtTflS4HZUhSAld9hABM1XhSVK?= =?us-ascii?Q?A0VtEGw502iVaxqR6M0EMhwD3a+Y6KZtFItXLkfCkWDsVF71Bt3mRyKsxPAY?= =?us-ascii?Q?s9qZKz+onqnuz+VpfjlEvVU663Fu2ewqsXHiPdydkKIwKq2WWyvHknjI9Ao0?= =?us-ascii?Q?iHiYg3h0rJI9Ez1Hn6gnn93DdYH+Bk5oSPWcBtV18Z+cAr9arS2A86mD3rVQ?= =?us-ascii?Q?4QhgUljrmWskHLvX36DfewjOn8rvvo+0yJEBthI32JvHg9/TtqnvNBjjbPLq?= =?us-ascii?Q?O/Tfc7YfnaLrt6y9ZjAe0uRp3sdrQTaf9DKxLQVupkvquDXs6uQrCzHAoUwz?= =?us-ascii?Q?3/cJbBCaOG46BjRNzbLBtR9rOXhpq6uS/zM/mpwNVICwnn/qT8lT34XlDsZ9?= =?us-ascii?Q?tmvJVUX5I+1cgFigbeAamQhe5LK/VqjqFul5QruVHnTUCk1MWkvQqSryzkaN?= =?us-ascii?Q?GEuz4Ev6/oIApy/vZMw4h9KNmNddFxaONK2expQUW21CRfebehqT3u7+PZI7?= =?us-ascii?Q?EYsFhPyG2v9SogsQRZMwNHnwbtDZrZ67kgSVqbQ6uZvTbETptsHuyQAKitDF?= =?us-ascii?Q?oJNs3NM5k3LxW5HUXpsT0GlrQFWCE1d8hL4MZfnbZ6JuVMKOxGtaBwjZwNgf?= =?us-ascii?Q?aeWXHlFU8EGQyXLAAT6ioA0vVH9NjDmDfgtthXtrt30CDINKDVlKynk0tJGm?= =?us-ascii?Q?X8FcrXz3zgOp8I2A3of8jX/Qu5rMy8uqb?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 5:tkJRkZ8aAymsWCE+oR8/jkE+Kyg4oHq+rPwb0AMP9DuZVxeWfek7KErlEPnx+Ss4j9vCiFOzUfOvjhsruEqeSxrT5lZ45h9VTP31B+j7t7s2RKh5YT3XwkMKAYim3z5tfMdF2FWso0Kje7AViW0gpg==; 24:6SL030+DuNSsGZi7Vwg6l2p+J4JS7xF2hyh7+D14zR9DEx+0l53CQAMMG0ltqKk77GRRek9Kmye2faj905JEJ4Zot5deBKDlAuMHFyLeS0E= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2015 04:33:44.2809 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1714 Subject: [dpdk-dev] [PATCH v3 1/4] eal: Introduce new cache macro definitions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Jerin Jacob
Dec. 14, 2015, 4:32 a.m. UTC
- RTE_CACHE_MIN_LINE_SIZE(Supported minimum cache line size)
- __rte_cache_min_aligned(Force minimum cache line alignment)
- RTE_CACHE_LINE_SIZE_LOG2(Express cache line size in terms of log2)
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
lib/librte_eal/common/include/rte_memory.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Comments
Hi Jerin, Please see some comments below. On 12/14/2015 05:32 AM, Jerin Jacob wrote: > - RTE_CACHE_MIN_LINE_SIZE(Supported minimum cache line size) > - __rte_cache_min_aligned(Force minimum cache line alignment) > - RTE_CACHE_LINE_SIZE_LOG2(Express cache line size in terms of log2) > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > --- > lib/librte_eal/common/include/rte_memory.h | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/lib/librte_eal/common/include/rte_memory.h b/lib/librte_eal/common/include/rte_memory.h > index 9c9e40f..b67a76f 100644 > --- a/lib/librte_eal/common/include/rte_memory.h > +++ b/lib/librte_eal/common/include/rte_memory.h > @@ -77,11 +77,27 @@ enum rte_page_sizes { > (RTE_CACHE_LINE_SIZE * ((size + RTE_CACHE_LINE_SIZE - 1) / RTE_CACHE_LINE_SIZE)) > /**< Return the first cache-aligned value greater or equal to size. */ > > +/**< Cache line size in terms of log2 */ > +#if RTE_CACHE_LINE_SIZE == 64 > +#define RTE_CACHE_LINE_SIZE_LOG2 6 > +#elif RTE_CACHE_LINE_SIZE == 128 > +#define RTE_CACHE_LINE_SIZE_LOG2 7 > +#else > +#error "Unsupported cache line size" > +#endif > + > +#define RTE_CACHE_MIN_LINE_SIZE 64 /**< Minimum Cache line size. */ > + I think RTE_CACHE_LINE_MIN_SIZE or RTE_MIN_CACHE_LINE_SIZE would be clearer than RTE_CACHE_MIN_LINE_SIZE. > /** > * Force alignment to cache line. > */ > #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE) > > +/** > + * Force minimum cache line alignment. > + */ > +#define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_MIN_LINE_SIZE) I'm not really convinced that __rte_cache_min_aligned is straightforward for someone reading the code that it means "aligned to the minimum cache line size supported by the dpdk". In the two cases you are using this macro (mbuf structure and queue info), I'm wondering if using __attribute__((aligned(64))) wouldn't be clearer? - for mbuf, it could be a local define, like MBUF_ALIGN_SIZE - for queue info, using 64 makes sense as it's used to reserve space for future use What do you think? Regards, Olivier
On Mon, Jan 04, 2016 at 02:15:53PM +0100, Olivier MATZ wrote: > Hi Jerin, Hi Olivier, > > Please see some comments below. > > On 12/14/2015 05:32 AM, Jerin Jacob wrote: > > - RTE_CACHE_MIN_LINE_SIZE(Supported minimum cache line size) > > - __rte_cache_min_aligned(Force minimum cache line alignment) > > - RTE_CACHE_LINE_SIZE_LOG2(Express cache line size in terms of log2) > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > > Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > > --- > > lib/librte_eal/common/include/rte_memory.h | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/lib/librte_eal/common/include/rte_memory.h b/lib/librte_eal/common/include/rte_memory.h > > index 9c9e40f..b67a76f 100644 > > --- a/lib/librte_eal/common/include/rte_memory.h > > +++ b/lib/librte_eal/common/include/rte_memory.h > > @@ -77,11 +77,27 @@ enum rte_page_sizes { > > (RTE_CACHE_LINE_SIZE * ((size + RTE_CACHE_LINE_SIZE - 1) / RTE_CACHE_LINE_SIZE)) > > /**< Return the first cache-aligned value greater or equal to size. */ > > > > +/**< Cache line size in terms of log2 */ > > +#if RTE_CACHE_LINE_SIZE == 64 > > +#define RTE_CACHE_LINE_SIZE_LOG2 6 > > +#elif RTE_CACHE_LINE_SIZE == 128 > > +#define RTE_CACHE_LINE_SIZE_LOG2 7 > > +#else > > +#error "Unsupported cache line size" > > +#endif > > + > > +#define RTE_CACHE_MIN_LINE_SIZE 64 /**< Minimum Cache line size. */ > > + > > I think RTE_CACHE_LINE_MIN_SIZE or RTE_MIN_CACHE_LINE_SIZE would > be clearer than RTE_CACHE_MIN_LINE_SIZE. OK. I will resend the next version with RTE_CACHE_LINE_MIN_SIZE > > > /** > > * Force alignment to cache line. > > */ > > #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE) > > > > +/** > > + * Force minimum cache line alignment. > > + */ > > +#define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_MIN_LINE_SIZE) > > I'm not really convinced that __rte_cache_min_aligned is straightforward > for someone reading the code that it means "aligned to the minimum cache > line size supported by the dpdk". > > In the two cases you are using this macro (mbuf structure and queue > info), I'm wondering if using __attribute__((aligned(64))) wouldn't be > clearer? > - for mbuf, it could be a local define, like MBUF_ALIGN_SIZE > - for queue info, using 64 makes sense as it's used to reserve space > for future use > > What do you think? IMO, it makes sense to keep "__rte_cache_min_aligned" as it will useful for forcing the minimum alignment requirements in DPDK in future structures. Thoughts? > > > Regards, > Olivier
diff --git a/lib/librte_eal/common/include/rte_memory.h b/lib/librte_eal/common/include/rte_memory.h index 9c9e40f..b67a76f 100644 --- a/lib/librte_eal/common/include/rte_memory.h +++ b/lib/librte_eal/common/include/rte_memory.h @@ -77,11 +77,27 @@ enum rte_page_sizes { (RTE_CACHE_LINE_SIZE * ((size + RTE_CACHE_LINE_SIZE - 1) / RTE_CACHE_LINE_SIZE)) /**< Return the first cache-aligned value greater or equal to size. */ +/**< Cache line size in terms of log2 */ +#if RTE_CACHE_LINE_SIZE == 64 +#define RTE_CACHE_LINE_SIZE_LOG2 6 +#elif RTE_CACHE_LINE_SIZE == 128 +#define RTE_CACHE_LINE_SIZE_LOG2 7 +#else +#error "Unsupported cache line size" +#endif + +#define RTE_CACHE_MIN_LINE_SIZE 64 /**< Minimum Cache line size. */ + /** * Force alignment to cache line. */ #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE) +/** + * Force minimum cache line alignment. + */ +#define __rte_cache_min_aligned __rte_aligned(RTE_CACHE_MIN_LINE_SIZE) + typedef uint64_t phys_addr_t; /**< Physical address definition. */ #define RTE_BAD_PHYS_ADDR ((phys_addr_t)-1)