From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0054.outbound.protection.outlook.com [104.47.0.54]) by dpdk.org (Postfix) with ESMTP id 54EC05F2D for ; Thu, 20 Sep 2018 16:26:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nEXB+v22krdeq/9YVdk7LLaJ9gHvSlSVHPYaBREbHjY=; b=xYXDd8rgOyExRfrEnyvETDgC/i6lERyA9LVWjvWH/uKiNGz1YQanoWjkD7FMV0rxQqqhVWCTjBRWa2DiR2xn+Ys4K8OB1yK24cYr64BH2A1or6xk3NRdtpIghb15PAoyBnLElkQFkMztKziI6CCSrJPcTQbib6vseFkoGPFlngQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; Received: from [10.232.134.144] (14.143.30.134) by AM0PR04MB4883.eurprd04.prod.outlook.com (2603:10a6:208:c5::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.18; Thu, 20 Sep 2018 14:26:29 +0000 To: "Ananyev, Konstantin" , Jerin Jacob , "Joseph, Anoob" Cc: "dev@dpdk.org" , "Awal, Mohammad Abdul" , "Doherty, Declan" , Narayana Prasad , Hemant Agrawal , "shreyansh.jain@nxp.com" References: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> <358d1b6c-26f2-b125-07a4-cfb1c0e2a57b@caviumnetworks.com> <2601191342CEEE43887BDE71AB977258EA95089D@irsmsx105.ger.corp.intel.com> <475cf471-b46a-671a-5485-0042c652430c@caviumnetworks.com> <2601191342CEEE43887BDE71AB977258EA954BAD@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258EA954E9D@irsmsx105.ger.corp.intel.com> <20180916105640.GA4803@jerin> <2601191342CEEE43887BDE71AB977258EA95724C@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258EA957E3A@irsmsx105.ger.corp.intel.com> From: Akhil Goyal Message-ID: Date: Thu, 20 Sep 2018 19:56:14 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB977258EA957E3A@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [14.143.30.134] X-ClientProxiedBy: BMXPR01CA0017.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:d::27) To AM0PR04MB4883.eurprd04.prod.outlook.com (2603:10a6:208:c5::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 049f9bd0-4f5a-4994-616f-08d61f050f0b X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM0PR04MB4883; X-Microsoft-Exchange-Diagnostics: 1; AM0PR04MB4883; 3:T4SkXSd/Mh01XIWNhyNvodQO9gSF4BKzRFJg5bF0A8MLVi4t8B+we7uxRfFVXbJALlzxK7aI0WQY99JfrW1w3p9cw8fJLKQXHcMJrgqtK7WcaEelEXzQ+NA7ipuLy1EtODyb4vzhnFCuDAG5TufLKB0CmbrRpTI9xGWDPkDdMfehjupTpEP2+W4hkrYjlAKjRlkOxzicLZblyMqUAyyQjFnKkHmUfsaxV8WWkZtO4elzl25GZN4EfENNncncjVR0; 25:kKnow4rp1ek5YvW05stbPVKqlGRNKfqdXRKvaupTHI33POTkoFFORYfV6cfMFcmk/rp3iFDxRSgKU73CxxOAhwNMFXIe3K/ivQt9LdQ+98KQC16PpIiLdedHItuga28QdkUoCemXzyJwkHonomI0ZEB4ACQP1wMQtUZ9lUjxwWHfGLGPBJlYz/lWpkRQ3+b/OE6tEphdeYGa1UFQ58/5a7d0UFJKtzEHYAnk2vrpiJwCM0fKNTPY8d3fL54tJiGn+xR6jDdnRMYxpyvkjpLpcrkjPZgoSFN82KYwsbTZ0Gg9Ac2RYMB7euh4xmm57RGeJPGA+NDwmHoJ09lJDXYOiA==; 31:ZEXe0763orL4g5LJjZ6MrgEkOi/+UoEfEFhyh/UFyBxe94JDQIJ1sXgiZ/6k4oAoCFvgcsFuwNGgS9SH7hwq6AtIrKjV8uPSEm79hT2wQ6URlaVx+O64U8Uk5czyLbM3ZLgf2h957OL3/ZfQSZ+WTh4sm76wG8tzBb8Vg3MoDMQQlp2Olp4ZYhlnPvD79cwuHoRo91ZzevGyK2yBxXBp04TAzXwedGaniSSc2kGf3rM= X-MS-TrafficTypeDiagnostic: AM0PR04MB4883: X-Microsoft-Exchange-Diagnostics: 1; AM0PR04MB4883; 20:FFWhHOsG0TjdcXZwxZv6g+c+H8Y51yxtNTMFJropSWj0W4/8UYPyRoPUuRSf10KqF/ettnLKkLesnYyYbi8HsMuvmkqS8iNjB+IX+MyEHdEAjxO3k6xQ82bEEjWnbHyiV9ZmTxZt6U5eyxbIycdVwtQww6OSEzik43StDTjC36aqu0QyOAFQmzw8YZeU1vvr1zdlojgN/MXP0qO2TDHQtNriXhx/fHNbENZGbAyvfcJMx27RvYbeHKZ3sv6imvMJ9IbvzFSwQuPrIf5plyyHjyZfAdZYxK2aXrREz/QGACqs039VmkCmHFs6pBsz813L3JLP1d0CRquOZWJv3M7Pe6peqgLvKVs00YYz2WqwzBW1hvVkfwtUzJMgSDsi/KIWuz9pgdP4ptdp8byR4LpibmNT+L1Kckg7+MkP+L6tFxynukeASz3QzCK782aPpFza8uTu6mz45JIZIEdzJx9soXP+OE/nrht79wgp+jHKl1oVrhOe2dy8UABBaMfDj03/; 4:DG1DGDGLmuOZEuBl5WzKMBWrISaSgYlYKU3etJ+ydmQ0BD9RUvd43iXdgMSHmgb/bpxZcmh/rYABGmTJn5CQC6kMsugzQjOTZsedgbF9TrjsO0/8GuyJx5jPKeTNTk6Gzw2srZV+2Re65l/3ivNV0enFVGWesWWUXCIvSUybYdkNl65rQOh1Fc8nn0Aux3q7KSZe8nd7Drq6QEGT677vDxmjbkvq8YVod0cNfzXANsM8ekDpvuvo4NRPeRNUGRyRTMbNh4S6IlqKqvQ3zAA7gIkay0fWwLs1Wb31qi7oav6P2aSGkK8SIiOeXckDIsHmJzCHcgHsWxZ27pFj7/cMTEbcYh2Y0U3ZGQUer2CBwEg= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(17755550239193); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(201708071742011)(7699051); SRVR:AM0PR04MB4883; BCL:0; PCL:0; RULEID:; SRVR:AM0PR04MB4883; X-Forefront-PRVS: 0801F2E62B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(136003)(346002)(366004)(39860400002)(396003)(376002)(52314003)(189003)(199004)(65806001)(16526019)(68736007)(93886005)(64126003)(7736002)(31686004)(305945005)(2870700001)(6116002)(36756003)(3846002)(6246003)(31696002)(86362001)(97736004)(105586002)(67846002)(50466002)(5009440100003)(476003)(26005)(16576012)(316002)(110136005)(65826007)(23676004)(52146003)(53936002)(4326008)(11346002)(5024004)(2906002)(106356001)(6486002)(44832011)(14444005)(386003)(6666003)(5660300001)(446003)(76176011)(478600001)(47776003)(66066001)(8676002)(25786009)(81156014)(3260700006)(58126008)(81166006)(8936002)(2616005)(956004)(54906003)(2486003)(229853002)(52116002)(65956001)(53546011)(486006)(77096007)(110426005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR04MB4883; H:[10.232.134.144]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTBQUjA0TUI0ODgzOzIzOlBacVdzTDZiY3BpNG84WE1JMlNpaFVJSlBP?= =?utf-8?B?dU9MTldNODFMNGIyNWUyWjEzbnhUZk1BeE1NUUlGN0NOMGRBdlI0T0lqV2Yw?= =?utf-8?B?NyttNDdFT2MvL0MyTmpGL010bEY2Yy9oS2M3MFcwWFVjQ0hZUHEvSWVSTTNo?= =?utf-8?B?c0hGZ3VjT0RBU1ZSaHFHVmdpdVc4a1FpbkdMV3hhQ2cvVGIzZEpuR1ExREdH?= =?utf-8?B?OFJIdWEwbWQ1cjFmcVRVSzY0bzhpaFpjcTkrRnZXUlBzbnNiTWdtaVZ2dDlt?= =?utf-8?B?ajZENU1wdzF6N01LZ1hBNXZhTDZtY0puakRzRjNma1htUk02L0tCdHBqT25o?= =?utf-8?B?c2RXYlRRVFFkZ1lRNVJ0dmcwcEZ6NWFXVm92SFVRaElERnR6RjdSWWdOU2hX?= =?utf-8?B?SXhVMmswM3F2am5scGh5TGdCanhDcVMyUllaaDFvclR3cEthUEM4ZWd3QWZv?= =?utf-8?B?RlBwM08waWVOY0dMTUFiSHkyeXRPWUtYUlhTb1d3bEl5WGdXQjJGOVVTcGFp?= =?utf-8?B?eldhY1FNeFpFS3U1VDlvV25MOW9aVFR4bFZyOEtaWXpoenE3c2lZUGxBZjZn?= =?utf-8?B?a0M4alZqbVFMSnZ6NUs0U0JmVGlKYldpS0NiRGlxRzZRSFBsK1hmNnpKOHR2?= =?utf-8?B?K3ZXb2NhWmkwb250ZmsrM3laVlNjTGtEcm5hdlFNY3I0SlQ3dEFLanYyZ3gy?= =?utf-8?B?SjNBQjBHaEcrdndyamV2aFkwY2dTYzhvMWtjMXd1eE1oRkxGWkNhRWVlK3E3?= =?utf-8?B?R2hMM0VjSHVhckxDNDZOWUU1T3laMHhDYUZzeWhyb2pWc01MM1hndWN3OEVk?= =?utf-8?B?NkVlQUpqKy9jQTdLN3QwbWdia1VUd3JvQlorczhhYlZUQS8wUXArb1pPZmtV?= =?utf-8?B?NERVKzliQkNPWWljdjBiRWtBYXpIQzF2ZE5aUitrY0l5TEg0dE9CMmREeXZj?= =?utf-8?B?MjFLTjZybjZCWUttV000ZWZpV3RObVV5MlBIQXdOMnUxMUxQUk5KTWx0WnZu?= =?utf-8?B?a0lGdXpzbDUrQ2ZCdGRrb09YK0dTNWVsYktkUGY1TVVXcjBHbjhHNGJFUDBQ?= =?utf-8?B?WlYxOXNSSkN5YmwwVEFwMmVodERDOWtSdEtGMzBiMXo2Tmp3c0RmQkdUaFc1?= =?utf-8?B?R0RtV1VhZzh1THBVaXJjcWdFUjU5aE9vcHdYQjJJc0VLd0RUZnhQd01rUmdn?= =?utf-8?B?YUI0VTJXaXIvdGd1Z2tCTEV4bG1LMzlONTM3YXBSejZHY1Mxci9vZHVmbFpL?= =?utf-8?B?SjQwRzFUM1IxYWMrMG9mWTlOd09veWZ3Ty94RUpiRHMzUFVnVGhtNkw1SUZE?= =?utf-8?B?UGNJdHhaSmNRbHAwNHlOT0hwWWoxV3dUdGZoSUZScE82R1UvOHQyZ2l1VjlR?= =?utf-8?B?Z2FoejlVSFVGQ2E5SW5mTDZwRWN4STNSbTFCL1VHMENKZTVoQml3WFRxb2dw?= =?utf-8?B?cWtBS2VlQWxmM3FyNDI2aDMrSW1yenBmT0FCNmJlTlFwang3VnJ6djZEVjRD?= =?utf-8?B?WFdKaGFXeUZ1TTNyQk14UEhhNTFBQU1CMGJJRXB1OFZuK3ZZRGx3WjRLQmV0?= =?utf-8?B?NUFnVU1SWXpiaGdBSVpEa2JIWnZYOWUrbHN0QzNnNTZNT2JYdmxRUUhuWnRk?= =?utf-8?B?MHViK0hQQ3g4bzZFaXpaazdIdEVxREVNaHNGOWpwV2Vla0YxdVJGZUEySVIw?= =?utf-8?B?K2hjaDdCZ09VS3dDSzM3NGdWVzB6aFRGYjRjQWJqc3IwN2oyUVp5RlM2UmJR?= =?utf-8?B?TFp3MUVBLyt6ZUdXRXArWlF5UTQ2cjkvVFF5VnRJRnZqdDZKM3RiMTlrdmE4?= =?utf-8?B?ck5BRGhmb0RTSVYvVlBRbklJekFFVkx3ZDRwWHg5ZjUreDAzVFhTdFBMcHZj?= =?utf-8?B?UDJUeVNjd0MwNWFUdUFma29WK3B1cm1JY2VjcFROMU55ZzdDc0QzR3d4QnJ2?= =?utf-8?B?ZHl1WHpHTWVHb3FpTzRmaHorSDlQYUtzTnBpZkMrZWZDNzlOazN6WDBnM0Nr?= =?utf-8?B?blFjcHVLalhIcGFkeFVmd1BTU0lCTTFMRWJZdGx0TnIwTStkMm9TQ09lOVdi?= =?utf-8?B?QkpXanZENHo3bE9rQ2UxRFR0Q0xpcityNmxabDRGclpoU1MyN0RPdm5LaDRy?= =?utf-8?B?TVB2aEIxN1Nic05UVFd4dnBzc3VkVEgvdHZJeWNCMlpGVnEvbG1SSXNVRDJJ?= =?utf-8?B?SEd5YzhWVXg0djc2RGlKRjF0eW9nPT0=?= X-Microsoft-Antispam-Message-Info: vNpP3iBG+gL2ARQYbZBh8q4psVnkcf7HfVpKlaJHdJ4I42oi0rqFNWdQjxaZ1WBFllBXuTrMXY/ncsyNPICjuLPCcaHfyiMuebBXOZABT2btrHQElwRLYGAw6CMyvwEVZdlz1Gms4RAfuyPIzicqdgsiTzuxrlw7qYBU/HfGb6a5upGRFTChPeMVatrPewanYjL/OSpX3QgE0R6G5H4HoAJReFWCtWb0V+sdWvikiRXjJiLFbEwzf4QVn1afmf0VdwzvshaNMgSVTyaAMLUs+cnk5GXiaOxAzV/rfmrx1z23ouAb2uPNE9o0qhS70fRHVrNEdYT/wD409V5htzn9Sq1S1bGCcVkUKXmIs+TEH9o= X-Microsoft-Exchange-Diagnostics: 1; AM0PR04MB4883; 6:4RvYsRg/uSQFuuvWw5YXJGVYsF3Eo+DJo/2+wtFQJ0ejwyDevUmW5ZHB6CeEW6gr5vIm+AyJxPWS+2IawfjyQ1ipBrPaDCwusDsw/DWesKnZ38As8eRQ+DS+10IemlrDndbi252x5Zy5x5MD2to0+vPW9/+Vt1ze9UNypk7tfR12xdy2TNP2lNLGqxVAuYo/UamWPjvwbRThFsK9ZhlD4l4T6DL41zJAM3Hbcx6GTN0Fc707iSZ1naxfL6NM6OQslVLgpah1uiJLfe39dH+z5KT7zluVpRysS8/LPPlqHSl0unIl8GMIm/2vDq8GfGMCn+sdEqpjC0dc1ALuNSisaFmmQMl1dm8xC14n8UKxr3d9/3s+yniTtgj6BsP5PmhZjM375C9sgXalzaAlQ2H4cd1G7E+Nu/kAscyEX2mKdQrHsBIPF0izk0uvDbHJRHJY6FoRoMrornrYzPDl17MU4Q==; 5:HKP4DuQH8IY2N8u+LePdHEDsVX2AaWyFmkWwoJMct5rEOSC+OmWoc7c+6Hdg0hOXFxCNWTzt6A/XiRG1CWPYkdSPa1Sios2sr8572uOr1ahynZ4YLzkdY4kD4IwpeFqMj8WcAMqiDT8CaVlhiPMgTv+Fm9vsfUqL5KfzyZ9TVgo=; 7:jS1baLUyOTwKSC0MMP9QBXEaPqEOntk2jPNYlzA4pSNWy9oCLKey2w2WXnQK7plsaFWBSeX5c/xGbYlSS5jnxzIfjP+xuU2XlrXqy8Oxmai1iecwktNsnXGBWmWC6UwTygpQaMemLaYdCmQKpNr3mfve2rKUR0WFzsChGOj/dm2pcoQldb+vqmjISl071y5r5cE63OVqERR3d34ClS1BkN+ksuW9UXqr/m34g2QKdq7sMxMLTQ5a7VUsSFVCYmNB SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2018 14:26:29.0113 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 049f9bd0-4f5a-4994-616f-08d61f050f0b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB4883 Subject: Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing 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: Thu, 20 Sep 2018 14:26:32 -0000 Hi Konstantin, On 9/18/2018 6:12 PM, Ananyev, Konstantin wrote: >>> I am not saying this should be the ONLY way to do as it does not work >>> very well with non NPU/FPGA class of SoC. >>> >>> So how about making the proposed IPSec library as plugin/driver to >>> rte_security. >> As I mentioned above, I don't think that pushing whole IPSec data-path into rte_security >> is the best possible approach. >> Though I probably understand your concern: >> In RFC code we always do whole prepare/process in SW (attach/remove ESP headers/trailers, so paddings etc.), >> i.e. right now only device types: RTE_SECURITY_ACTION_TYPE_NONE and RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO are covered. >> Though there are devices where most of prepare/process can be done in HW >> (RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL/RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL), >> plus in future could be devices where prepare/process would be split between HW/SW in a custom way. >> Is that so? >> To address that issue I suppose we can do: >> 1. Add support for RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL and RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL >> security devices into ipsec. >> We planned to do it anyway, just don't have it done yet. >> 2. For custom case - introduce RTE_SECURITY_ACTION_TYPE_INLINE_CUSTOM and RTE_SECURITY_ACTION_TYPE_LOOKASIDE_CUSTOM >> and add into rte_security_ops new functions: >> uint16_t lookaside_prepare(struct rte_security_session *sess, struct rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t num); >> uint16_t lookaside_process(struct rte_security_session *sess, struct rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t num); >> uint16_t inline_process(struct rte_security_session *sess, struct rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t num); >> So for custom HW, PMD can overwrite normal prepare/process behavior. >> > Actually after another thought: > My previous assumption (probably wrong one) was that for both > RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL and RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL > devices can do whole data-path ipsec processing totally in HW - no need for any SW support (except init/config). > Now looking at dpaa and dpaa2 devices (the only ones that supports RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL right now) > I am not so sure about that - looks like some SW help might be needed for replay window updates, etc. > Hemant, Shreyansh - can you guys confirm what is expected from RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL devices > (HW/SW roses/responsibilities)? > About RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL - I didn't find any driver inside DPDK source tree that does support that capability. > So my question is there any devices/drivers that do support it? > If so, where could source code could be found, and what are HW/SW roles/responsibilities for that type of devices? > Konstantin > > In case of LOOKASIDE, the protocol errors like antireplay and sequence number overflow shall be the responsibility of either PMD or the HW. It should notify the application that the error has occurred and application need to decide what it needs to decide next. As Jerin said in other email, the roles/responsibility of the PMD in case of inline proto and lookaside case, nothing much is required from the application to do any processing for ipsec. As per my understanding, the proposed RFC is to make the application code cleaner for  the protocol processing. 1. For inline proto and lookaside there won't be any change in the data path. The main changes would be in the control path. 2. But in case of inline crypto and RTE_SECURITY_ACTION_TYPE_NONE, the protocol processing will be done in the library and there would be changes in both control and data path. As the rte_security currently provide generic APIs for control path only and we may have it expanded for protocol specific datapath processing. So for the application, working with inline crypto/ inline proto would be quite similar and it won't need to do some extra processing for inline crypto. Same will be the case for RTE_SECURITY_ACTION_TYPE_NONE and lookaside. We may have the protocol specific APIs reside inside the rte_security and we can use either the crypto/net PMD underneath it. Moving the SPD lookup inside the ipsec library may not be beneficial in terms of performance as well as configurability for the application. It would just be based on the rss hash. Please let me know if my understanding is not correct anywhere. -Akhil