From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0065.outbound.protection.outlook.com [104.47.40.65]) by dpdk.org (Postfix) with ESMTP id 1502A1E2B for ; Fri, 13 Jan 2017 17:22:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=icxe7HCc/ITNXCtgMlHJmjuYz84sEuy5GoIsPigLe+k=; b=SdhsmnPhj/atcUOHjcZ3IYE3eE3oapXB0rbAM8qZyvt3IdqqSshFs2PBFkEUHQ2/n6JpArMHnb/xE6bxGaq5NFebAHVX5ayE1u/5XAQ6Zu6XGUYfyOA1i5bHNFcH0aoS5le3dwxcp3JtRfcAnQjdeMifpPATtw7iViupY9m9I7w= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (171.61.97.114) by BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Fri, 13 Jan 2017 16:22:07 +0000 Date: Fri, 13 Jan 2017 21:51:53 +0530 From: Jerin Jacob To: Ferruh Yigit CC: , , , , , , , John Griffin , Fiona Trahe , Deepak Kumar Jain Message-ID: <20170113162152.GC17956@localhost.localdomain> References: <1482832175-27199-1-git-send-email-jerin.jacob@caviumnetworks.com> <1484212646-10338-1-git-send-email-jerin.jacob@caviumnetworks.com> <1484212646-10338-16-git-send-email-jerin.jacob@caviumnetworks.com> <6bb9980b-f546-38d5-044a-63507510f6a5@intel.com> <20170113081641.GA17635@localhost.localdomain> <20170113145753.GB13558@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Originating-IP: [171.61.97.114] X-ClientProxiedBy: BM1PR01CA0031.INDPRD01.PROD.OUTLOOK.COM (10.163.198.166) To BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) X-MS-Office365-Filtering-Correlation-Id: 073d5563-ed3c-4eef-e27c-08d43bd053fe X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 3:qdc5YhTYtSEPeF2mrQ+3ytBpHmy4rIJA3oIJuWc4Omjuc4/EmYHHz4pAN+kNnQrCdClm7On8CtzcYCMdsRW8VTUSrWWMdE+y3NjRgSl4cwIJUUvMjG0v8qugkzD/7ZikdjVKZzboNBcO9gtVESQNwI8K3ii7C/FbqmoAq/qXSxtbuzWMPTW5+gt22RzkqQ0PI7+BK/2yLXgy8bDeGB9wp0m/Jh7jnlH/jwfcH2YcntzXKn/+hBEFZhfL0vYTojpmcNMOxutVjLosmssuL/JZrw==; 25:6SL71trRf67b+shhPtJQAzmIf6OZ0SFCZe5CyHOCXUtxcVimu2PtW/Yz6P80not9RXEFo7rBlbKXs11tmNelQhG2QBROWjK9Zod8hx5XlX9gA5CvDwxu7plRxi7dltZOO/LRjIbz47NHMA0THw3r+er2slRJFOz/TEDMZlWk9qy5fn1QamZ2mWDb7y20B+NZXt3b8oONshwE2sbh35XRlSv+4GjJCtGBzV0MaB7TNw94NTcdwmO6tht7BHMTkPTVnoquR6HUReVjMLluyRZoEv9Zijv6hTpNnfAa4PXTbNHLP5lgtTAAHCKPT44d2cYtT3FtjwEZVG8nPfiqA7FaSVg0A0tU+lZvoab3xarCXvQPJP7LThQwzLAGVMaeunC+nq/9J8EF030KELnqcQGHSw08pVIEVw+fTfPWR2NRCoHuHC+l+aBiyGvaWtEy3NByOsNKsCGEkISmRvZYY3riSA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 31:KOd7CLC9o7LO+DKPwsMJOgavLp4NN0sjn2D3S+8dDpI1sAlfwR7nFDvLZY/F18fFigMBd6gj2+vp3Fcs0UkXo8tqLGUoxkFKOeeZ6QiuWadT1Tv/2PuWvHEP8mDZ8AvIPumMn9fGpL4NEkWyNjl/0m2CucpUpts7Ln3MDloo++E57Pt62MJjXDJ/DQLxXqoZ/paQV5vOhWmjJ8lmZV7LOIcBYjNvHKy6eU3s1uKyxoBJocPfq75kHKEV+F1tZx1P; 20:y5lisOuezZiywbWWVNdB5SnD7lUs87a1RzNLflMKVmW9p//qUDxMwbYMfYuaUWmpIfoVyDTKNsD1hXdKgv7x7/0TRrmPo3I3cacR8Vwo45LdcLZxHo9km+6RBiXP50LtUByWTTYy49Tgevs9tOHZr3tFua84dQ2Uh8fUC6C56vqNR4NXrJ7U3JOgZsovV2pRQl1JnGR5PzZKKQsSwE3HMyOx1OXThbVUwMdE/M6N0SViTgrOHHqqP7/QEHV5cLDyXFnd0GhilXJz7R/ySNLj/IvQ+PiLtN+m07YnnlnVzlHMNntnzVM9b1g7nRc3kXaLhlQbgqul1fbFnU5KJDKa/50ZCmfBFk9hOanvx88hRFYiVkQH0kJ+QcwEUwmKX+452FZRK6xm/dwsIRPLTvVpNcoK0FNRHqAlr41aRp8U0qpAJsp/JZWbj+AjCF/fUapwG+0AmfFsvdmVMIsRqTbD8V0bsaDoj4tDn5HQAqZ5TusKINt10P2PthmgNK1zz0afc7nPRE2BYTaeXc5HRA5jL3X2H/guXPgC5DIqcvjqhTM2O2C29kdRw0i/c3urtnpYDdfbtz9pUoeSClcYLsAHeqe6fsCqgL0XFq7uE5d+zuw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(788757137089)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BLUPR0701MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 4:BqSFWtWXGEoK4xlvJ+ydGj3xKmNEC3Z0tJBQrlDOeQhREGkhLmcnVipcgVCT7OrHaansT+5+YTpAOjKCzzvQm8MHXRWSFodd/UuDv6B2JG2vBxrBzSMI+CuemQMOe7S/10XToVxtElAikKMChHj8OL2gaqEzYn2m/DBszP/95UaLiElPwrn2iUeJQPPp2IP0uVHaZV91dsWRGlmlXO9PylxMyXySR8KZVVpixF0Mx4LG/36Zmkn4k+R5dSuHJk4aLBKx8t4huNOZZdhct1hQd7Yn9VPnGOjyVIDt4qFTsO3KL+so8lq1d9vfB7eeNsPFvsQzInKerGnJ5GVssKrgWVmcUtsOGxS3r4Ukd+aGHungcA6GClC07xKloz0tqh/hyR+KnrGoArNFc+Okv9/PNrWdBkchCa5NoVKObht0AL4NI4bTy7pjnc9Y9CmJ5kCZ9U5wHrjVxfdPHghy2lDmD+ut551dRGUASjylz4JapRtaqU8Y15CDpbD4FOIbHZG8SOcXizpXhumaDp6cvin+oR/El+ypzLAxByKilD0fO+wJCvryFgp6QzEsWEy8HC+mT3gb1FDVr7hrG2Iz4F2ommxPeKP79gNgsre2YBAX5U1qYpmDhzKYFq9Ss+aJFj/PqlYdjxuu7o4o0HA8C58ZZA== X-Forefront-PRVS: 018632C080 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(39450400003)(76104003)(199003)(377454003)(189002)(24454002)(25786008)(68736007)(92566002)(229853002)(38730400001)(6506006)(189998001)(55016002)(81156014)(61506002)(47776003)(66066001)(81166006)(6666003)(8676002)(50986999)(76176999)(54356999)(105586002)(7736002)(5660300001)(4001350100001)(6116002)(42882006)(7416002)(2950100002)(6916009)(97736004)(83506001)(106356001)(42186005)(93886004)(3846002)(54906002)(33656002)(9686003)(110136003)(305945005)(4326007)(23726003)(50466002)(2906002)(97756001)(46406003)(101416001)(1076002)(11001)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1714; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1714; 23:m5IYkUH2CjUkfxhazTEPSUc4560KGb+ibORlfwg?= =?us-ascii?Q?jVBfa9S8gVIM4tdC4zC9xdJ2nMRfuMy52hm6ZAMlpJm23Aiqi6udNWX0a1DC?= =?us-ascii?Q?LN3PabonFr9JoCT8jveUtCrWUmYtzTsrktc55wdXZh7OcTG7jiauMDMyRp6O?= =?us-ascii?Q?lm9c7c7duAfzOIGzueb9U+IwA/wgZ/fJLwXyNbkC2M3XbtIJvqRf8mgJRrFm?= =?us-ascii?Q?K2fG52vOFz4hVwh1KkAzS1PelbIE/M5sbKzn5Y0dkeFBG3NW3DQbltxb3jAR?= =?us-ascii?Q?nDpukaUsG4gjytcXSSIhqvNTHlqMWmOD5omDRbyzHT2IEyNm8K6aCRVnMFW5?= =?us-ascii?Q?60TxERe1u6ssZH5IobUN7/3m3AMqm5O469xYESfdsRsKK5/gj4kneHas6p8r?= =?us-ascii?Q?2StgYI/lVcFWoD78he9nCOoW1pV1Iy/72UoEOkI5tDOFFuPl/gSwa+XQ+4Gh?= =?us-ascii?Q?5e6MbNIWoTtnS06sAxj4cSj8lbgmc+hPrwJjN/mC3Zl3zstsiLAGa9WFFlJw?= =?us-ascii?Q?akvihUcPPw3r3h5LarZ+6rEn03Bnlk8JJv3/zGSPzsM+GyPjBenYSV4fkqvB?= =?us-ascii?Q?6yhBBp1SmE6ItX3wPWiMRSBnYkeQE/kJF1zTo8bCB6srckniShKdZWt1a3uE?= =?us-ascii?Q?rk1dNrgJD6nLvCR5wCBPyBGIf2M6bzptp/NAMSuys5CPZxnogVepcznJvfrQ?= =?us-ascii?Q?CwjI+nYHrTtSd8LdPf2WhguFO6y+n7/XrPovHmwhQa91zoBpg36KpAJJIQbQ?= =?us-ascii?Q?tpfjodhgg10VTQdYZNVtocXug6i40vlxLXyzqs6Zn8TxB8Izl5mplUf0nIYa?= =?us-ascii?Q?Yh4KgnMSBLCmcmXdq4rTmUaQRFOGzTEUETGFnV+OTtgZUDmrPgV4JyEt1rrT?= =?us-ascii?Q?arNuSA0r5/nVuGX/qtO7+GG4TsKdQwQHNW9Mz1DLdlCSxNTEHyX/VqN1ydvs?= =?us-ascii?Q?IYDyGo4Vp5DJGWJ8RC52BhBcpa+XgNX+/p/LffJKdohE+9wIef5Zc+nIITts?= =?us-ascii?Q?NJ5RbvH9KzctH/KPYyy2JdPLx5yMUFYvhHWNar0f+mAg1ttxvHUK9IZcygNV?= =?us-ascii?Q?YlPzJQqLt/kbiKlT3HVugkuByMufb2CQPZaWDGJqV0Sws+fnCQmsePsnHN55?= =?us-ascii?Q?psmmmpMFkofjlJkxyiOvNM8tIE8X+6MIFRUhLw4oqUvcRaBEREC6eUKe1C9S?= =?us-ascii?Q?uAlbCMbB++gGXhXKDONI7mx2mNrS4+ffdLeEI0xdZyTGKfw/rCKGUFoWewtF?= =?us-ascii?Q?XidpI2vQYmJQ7Y/WoMTVjVHQrSyMZS5G1lX3zMs4+oEtq4V6NrnsfwM2+Wez?= =?us-ascii?Q?9aPTbs2fSNl3yD3A94pyRGabm2oZ9UG/sZY/X4ne+6FcIz/8K7zA+3CaBc0s?= =?us-ascii?Q?aATHiM+K0Gh5e/MGvWZQYuzxxWi0=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 6:qBamEsGHwi8f/X4gao2x5QCejwlmDNYWipKJS+2z7+58jZe/2pnPTrnhFDYu43lSXGeXJXua4ie8ptNHlQO2RFDB3sTVJaGYIHr0OVpAOQda+jjr4HjL6Na3bg4y+PYn8grE4kxxSRCG1BciUi+j2F3YrMtxphxktudLC6evjkYRzkpM0qLZ0UAQAMpebngLMvQPJp2Z6d8QMv1mkUVkLVWji86Gq7gGp27lR2JvgnQiisVJP+tbKAvG/vxKe0SjYo+2EpgOlkmw9MS54F9DhcB7cyhmBUPhabreoSwTS2Azl2E9quyxAYoT0w2mlvBiA4AKvsqNfyaoBmOVIFZeGJJDgTvwNhYbOWHEo7sHWe7DF9+rRm/dGpbD238Ii3thBzySe/0NCvSL20vFdTGjdWgGZtrLuYYLggivzZbcpoI=; 5:m1IyR2sl5pSNQuDfRIMY7RrtHTvqkTpXNg1/D1n2jHIFIuCR81Yb9DUvF+uA8d6HOBMRS3uBMdGQFJv3iDw5tj770auv1npiQMSKQokvh3aj2jZrd8qYTyd+cDmQSz+yTpctmkG7MnlXZOyIOYz9VsYwHXFdKdqunwFinTOYiOM=; 24:LuHxoPROpZXwW8QAO8nYSM9wAZPom6IUGdMKrCfk+VkyZL3S8XPtPa6AT58/VdQjbqy9oRKLZXIHPRq4u8Hk6E5E0uvFGh0vPnnp2gqcjv4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 7:S/lBksQ0vrYykDRr8IvtTt2+BGTjPJXIX8VmUVLS6SZ+QxH5UllqF0ND+m+Ht048x5YDR+oCPAE/tWsJNF50JDQBiQsOMKCLBLYwDEJWvV8+nYqoOhNnT2AZ+17f8Fii3/nEW0SX8ZTeInS8MZUvNmIIfIqmkE2+6NzUwFaQOFbPGziM/iIW0AkySjd+qfQZjx8fm8NSMjO/x6i5DMxHllq/xrpgrHJM0bxL3tKhkRw4oVscwlVvNQrdy98OZ6HehL5hlRL+TikUjX1JddNqrtUnJ4CjrlYE8yKdzJS47GrntWKkN5PF7cpBjH9RYD9r5x/IbL/YeEcXj6+XQ5IwNlGksjkN4xeXN3wv6lR6PHw8WpYE66g64ggvl1pavroeVDS5ipRvu8SloEX/oWRYyzHVM4kCTQvRFEfg0a+bj8hfid3ijQY3Vr1c0lLPM6S5ct4ZL8rksWNebMt3dN6MFA== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2017 16:22:07.0532 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1714 Subject: Re: [dpdk-dev] [PATCH v3 15/29] crypto/qat: use eal I/O device memory read/write API 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: , X-List-Received-Date: Fri, 13 Jan 2017 16:22:14 -0000 On Fri, Jan 13, 2017 at 03:50:59PM +0000, Ferruh Yigit wrote: > On 1/13/2017 2:57 PM, Jerin Jacob wrote: > > On Fri, Jan 13, 2017 at 11:32:29AM +0000, Ferruh Yigit wrote: > >> On 1/13/2017 8:17 AM, Jerin Jacob wrote: > >>> On Thu, Jan 12, 2017 at 07:09:22PM +0000, Ferruh Yigit wrote: > >>>> Hi Jerin, > >>>> > >>>> On 1/12/2017 9:17 AM, Jerin Jacob wrote: > >>>> <...> > >>>> > >>>>> +#include > >>>>> + > >>>>> /* CSR write macro */ > >>>>> -#define ADF_CSR_WR(csrAddr, csrOffset, val) \ > >>>>> - (void)((*((volatile uint32_t *)(((uint8_t *)csrAddr) + csrOffset)) \ > >>>>> - = (val))) > >>>>> +#define ADF_CSR_WR(csrAddr, csrOffset, val) \ > >>>>> + rte_write32(val, (((uint8_t *)csrAddr) + csrOffset)) > >>>> > >>>> For IA, this update introduces an extra compiler barrier (rte_io_wmb()), > >>>> which is indeed not a must, is this correct? > >>> > >>> AFAIK, Compiler barrier is required for IA. I am not an IA expert, if > >>> someone thinks it needs to changed then I can fix it in following commit > >>> in this patch series by making rte_io_wmb() and rte_io_rmb() as empty. > >>> > >>> Let me know. > >>> > >>> AFAIK, Linux kernel code has a barrier in readl/writel for IA. > >>> > >>> Typically we don't use any non relaxed versions in fast path.In fast > >>> typically all the drivers has explicit write barrier for doorbell write > >>> and followed by a relaxed version of write. IMO, In any event, it won't > >>> generate performance regression. > >>> > >>> [dpdk-master] $ git show > >>> 70c343bdc8c33a51a9db23cd58122bdfc120a58f > >>> commit 70c343bdc8c33a51a9db23cd58122bdfc120a58f > >>> Author: Jerin Jacob > >>> Date: Mon Dec 5 06:36:49 2016 +0530 > >>> > >>> eal/x86: define I/O device memory barriers for IA > >>> > >>> The patch does not provide any functional change for IA. > >>> I/O barriers are mapped to existing smp barriers. > >>> > >>> CC: Bruce Richardson > >>> CC: Konstantin Ananyev > >>> Signed-off-by: Jerin Jacob > >>> > >>> diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic.h > >>> b/lib/librte_eal/common/include/arch/x86/rte_atomic.h > >>> index 00b1cdf..4eac666 100644 > >>> --- a/lib/librte_eal/common/include/arch/x86/rte_atomic.h > >>> +++ b/lib/librte_eal/common/include/arch/x86/rte_atomic.h > >>> @@ -61,6 +61,12 @@ extern "C" { > >>> > >>> #define rte_smp_rmb() rte_compiler_barrier() > >>> > >>> +#define rte_io_mb() rte_mb() > >>> + > >>> +#define rte_io_wmb() rte_compiler_barrier() > >>> + > >>> +#define rte_io_rmb() rte_compiler_barrier() > >>> + > >>> /*------------------------- 16 bit atomic operations > >>> * -------------------------*/ > >>> > >>> #ifndef RTE_FORCE_INTRINSICS > >>> > >>>> > >>>> If so, does it make sense to override these functions for x86, and make > >>>> rte_writeX = rte_writeX_relaxed > >>>> rte_readX = rte_readX_relaxed > >>>> > >>>>> > >>>>> /* CSR read macro */ > >>>>> -#define ADF_CSR_RD(csrAddr, csrOffset) \ > >>>>> - (*((volatile uint32_t *)(((uint8_t *)csrAddr) + csrOffset))) > >>>>> +#define ADF_CSR_RD(csrAddr, csrOffset) \ > >>>>> + rte_read32((((uint8_t *)csrAddr) + csrOffset)) > >>>> > >>>> This patchset both introduces new rte_readX/rte_writeX functions, also > >>>> applies them into drivers. > >>>> > >>>> While applying them, it changes the behavior. > >>>> Like above code was doing a read, but after update it does read and > >>>> read_memory_barrier. > >>>> > >>>> What do you think this patchset updates usage in a manner that keeps > >>>> behavior exact same. Like using rte_read32_relaxed for this case. > >>>> And doing architecture related updates in a different patchset? > >>> > >>> Need to use rte_read32 at this commit otherwise it will break for ARM. > >>> That's was all point for this patchset. > >> > >> Why it breaks the ARM, is it because rte_*mb() updated for ARM in this > >> patchset (patch 7/29) ? > > > > Yes. > > > > > >> > >> I believe it is good to make these modifications in two phase: > > > > It is in two phases only. First introduced the API with implementation and > > enabled in each driver. Why did you think other-way around it is better? > > For two things: > 1- If something goes wrong, find the source of problem easier. How? Are you suggesting like this below, 0) Introduce rte_io_?mb() 1) Introduce readxx_relaxed and writexx_relaxed 2) Change all the drivers with readxx_relaxed and writexx_relaxed(15 change sets) to keep the same behavior 3) Introduce readxx and writexx 4) revert step 2 changes and make driver based on readxx and writexx(again 15 change sets) Instead of(existing one) 0) Introduce rte_io_?mb() 1) Introduce readxx_relaxed and writexx_relaxed 2) Introduce readxx and writexx 3) Change all the drivers with readxx_[relaxed] and writexx_[relaxed] Proposed scheme makes driver authors to review two check-ins. And git bisect fail on fourth case of instead of thrird case with existing one. Not sure what we soloving here? Thomas, Any thoughts? > 2- Make architectural changes obvious, right now it is a little hard to > see, and this again for item 1. > > But I also would like to hear more comments before you change/try anything. > > > I can rework and test if there is any value addition. If you concerned > > about git bisect ability then I don't think we are loosing that in this > > model. > > > > Thoughts? > > > >> - First replace old usage with rte_readX/rte_writeX while keeping exact > >> same behavior > >> > >> - Second, do architecture specific changes. Both in eal and drivers > >> level if required. > >> > >> Thanks, > >> ferruh > >> > >>> For performance regression, we can always verify by taking delta > >>> between this changeset and the previous changeset. If you think, I need > >>> to make rte_io_wmb()/rte_io_rmb() as empty for IA then I could do that > >>> as well. > >>> > >>> > >>>> > >>>> This both makes easy to see architecture specific updates, and makes > >>>> easy to trace any possible performance issues by this patchset. > >>>> > >>>>> > >>>>> #define ADF_BANK_INT_SRC_SEL_MASK_0 0x4444444CUL > >>>>> #define ADF_BANK_INT_SRC_SEL_MASK_X 0x44444444UL > >>>>> > >>>> > >> >