User Tools

Site Tools


Session Start: Wed Sep 23 21:07:12 2015 Session Ident: #opnfv-dpacc 03[21:07] * Now talking in #opnfv-dpacc 02[21:08] * gg_ (c6af4426@gateway/web/freenode/ip. Quit (Ping timeout: 246 seconds) 03[21:46] * mpaolino ( has joined #opnfv-dpacc 03[21:55] * keith-wiles (c0373628@gateway/web/freenode/ip. has joined #opnfv-dpacc [21:55] <keith-wiles> Hello everyone 01[21:56] <Lingli_Deng> Hi Keith [21:57] <keith-wiles> No Audio again today [21:57] <keith-wiles> Maybe a very small group as most will be at the Linaro Connect I guess 01[22:00] <Lingli_Deng> Sorry about that. 03[22:00] * Magnus_ (c0c69725@gateway/web/freenode/ip. has joined #opnfv-dpacc 01[22:01] <Lingli_Deng> Yes, I got several out of office notification from guys attending Linaro Connect. [22:02] <keith-wiles> Do you want to proceed or cancel 03[22:02] * Kin-Yip_Liu_Cavi (62d2713f@gateway/web/freenode/ip. has joined #opnfv-dpacc [22:02] <Magnus_> Nobody from Linaro or ARM is going to make it today, unless they get up early [22:03] <Magnus_> As you say, they are at Connect 03[22:03] * Steve_ (63f194e3@gateway/web/freenode/ip. has joined #opnfv-dpacc [22:03] <Kin-Yip_Liu_Cavi> We just had a ARMband conf call one hour earlier 03[22:03] * subha-fsl (6bdfd219@gateway/web/freenode/ip. has joined #opnfv-dpacc 01[22:03] <Lingli_Deng> I missed that one, I waited on GTM for 20 minutes. [22:03] <keith-wiles> OK, lets wait for a few minutes 03[22:04] * BobD (6c14796e@gateway/web/freenode/ip. has joined #opnfv-dpacc [22:04] <Kin-Yip_Liu_Cavi> Bob used an ARM bridge for today to avoid conflict on GTM 01[22:04] <Lingli_Deng> @Kin-Yip Did you use the GTM call? [22:04] <collabot> Lingli_Deng: Error: "Kin-Yip" is not a valid command. 03[22:05] * olli_ (46232702@gateway/web/freenode/ip. has joined #opnfv-dpacc 03[22:05] * mikruots (c2fb77c6@gateway/web/freenode/ip. has joined #opnfv-dpacc 01[22:05] <Lingli_Deng> Hi guys, shall we start now? 03[22:06] * Bob_ (18068276@gateway/web/freenode/ip. has joined #opnfv-dpacc [22:06] <keith-wiles> OK 03[22:06] * Pradeep (32353ca0@gateway/web/freenode/ip. has joined #opnfv-dpacc 01[22:06] <Lingli_Deng> I would like to go over the tasks for B-release documentation of dpacc 03[22:06] * olli_ (46232702@gateway/web/freenode/ip. has joined #opnfv-dpacc [22:06] <Bob_> sorry i was late 03[22:06] * Bose (31cfbb83@gateway/web/freenode/ip. has joined #opnfv-dpacc [22:07] <Bob_> Bob_ is Bob Monkman btw [22:07] <Bob_> not to be confused with Bob Doud Bobd 01[22:07] <Lingli_Deng> I spent some time on the etherpad for our documentation, and here is a summary which I would like to use for today's discussion. 01[22:07] <Lingli_Deng> 01[22:07] <Lingli_Deng> Hi Bob, Bob [22:08] <Bob_> hi 01[22:08] <Lingli_Deng> Would everybody go to [22:09] <Bob_> yes..I have two windows up [22:09] <keith-wiles> Got it up now 02[22:09] * olli_ (46232702@gateway/web/freenode/ip. Quit (Ping timeout: 246 seconds) 01[22:09] <Lingli_Deng> I would like to go over the changes I have made or suggest to be made to the current work items of dpacc for B-release 03[22:09] * gg (6add96d9@gateway/web/freenode/ip. has joined #opnfv-dpacc [22:09] <keith-wiles> Freenode is not very stable :-( [22:10] <olli_> @keith I had to restart my browser which hang so not Freenode's problem (this time) [22:10] <collabot> olli_: Error: "keith" is not a valid command. 01[22:10] <Lingli_Deng> In summary, 4 items to be worked on for B-release 01[22:10] <Lingli_Deng> two added, gap analysi and test spec 01[22:11] <Lingli_Deng> for gap analysis, there are separate links to pages dedicated to dpdk/odp/virtio/… 01[22:11] <Lingli_Deng> As you can see from 03[22:11] * lab_ ( has joined #opnfv-dpacc [22:11] <Bob_> Yes…the gap analysis page looks like we can fill it in 01[22:11] <Lingli_Deng> Is there anything missing from the list? 03[22:12] * lab_ is now known as NokMikeR 01[22:12] <Lingli_Deng> Gap Analysis for Data Plane Acceleration Framework 01[22:12] <Lingli_Deng> Table of Contents 01[22:12] <Lingli_Deng> gAPI 01[22:12] <Lingli_Deng> dpdk: drafting in: 01[22:12] <Lingli_Deng> odp: drafting in: 01[22:12] <Lingli_Deng> guest-host interfaces 01[22:12] <Lingli_Deng> virtio: drafting in: 01[22:12] <Lingli_Deng> sr-iov: drafting in: 01[22:12] <Lingli_Deng> mgmt interfaces/components 01[22:12] <Lingli_Deng> openflow: drafting in: 01[22:12] <Lingli_Deng> openstack: drafting in: 03[22:12] * Skip_ (4066f906@gateway/web/freenode/ip. has joined #opnfv-dpacc 03[22:12] * Mario_ (d98c608c@gateway/web/freenode/ip. has joined #opnfv-dpacc 03[22:12] * Srini_Intel (86868b46@gateway/web/freenode/ip. has joined #opnfv-dpacc [22:13] <Bob_> I think the topics are what I expected, yes [22:13] <keith-wiles> Nothing I can see at this point time 01[22:13] <Lingli_Deng> 01[22:14] <Lingli_Deng> Gap Analysis for Data Plane Acceleration Framework 01[22:14] <Lingli_Deng> Table of Contents 01[22:14] <Lingli_Deng> gAPI 01[22:14] <Lingli_Deng> dpdk: drafting in: 01[22:14] <Lingli_Deng> odp: drafting in: 01[22:14] <Lingli_Deng> guest-host interfaces 01[22:14] <Lingli_Deng> virtio: drafting in: 01[22:14] <Lingli_Deng> sr-iov: drafting in: 01[22:14] <Lingli_Deng> mgmt interfaces/components 01[22:14] <Lingli_Deng> openflow: drafting in: 01[22:14] <Lingli_Deng> openstack: drafting in: [22:14] <keith-wiles> The gaps listed are fine 01[22:14] <Lingli_Deng> Anything missing from the list that we should look at? 01[22:14] <Lingli_Deng> Great. 01[22:15] <Lingli_Deng> Then I would like to call for contribution to these items. [22:15] <Bob_> yes…we can work on the items we have inputs on 01[22:16] <Lingli_Deng> Which ones are you referring to, Bob? [22:16] <keith-wiles> I can do the DPDK gapi one and Magnus can look at the virtio with others if needed [22:17] <Bob_> We can certainly take the ODP Gap and see what we can contribute to virtio [22:17] <Bob_> I was not aware of what was expected in openflow or sriov [22:17] <olli_> I was assuming I would help Magnus with whatever needs to be done for virtio-crypto. [22:17] <Magnus_> Yes please [22:17] <Bob_> thx Ola [22:17] <olli_> But does the virtio gap analysis go beyond virtio-crypto? 01[22:17] <Lingli_Deng> Thanks Ola. what about sr-iov or openflow? [22:18] <keith-wiles> At this point lets focus on crypto for now [22:18] <subha-fsl> we have added text in virtio gap for ipsec [22:18] <Bob_> I must have missed expectatons on sriov and openflow [22:18] <Magnus_> SR-IOV, is that not part of the KVM-hypervisor group's charter? [22:18] <Magnus_> @olli Let us start with vritio-crypto, then go up [22:18] <collabot> Magnus_: Error: "olli" is not a valid command. [22:18] <keith-wiles> SR-IOV is a hardware issue and I do not see how it relates to DPACC now [22:19] <Magnus_> olli, let us start with vritio-crypto, then go up [22:19] <subha-fsl> @magnus @olli we can contribute to virtio-crypto as well 01[22:19] <Lingli_Deng> I am sorry, I crossed sr-iov from the eherpad page, but it remains in the text here. [22:19] <collabot> subha-fsl: Error: "magnus" is not a valid command. [22:19] <olli_> ok 01[22:19] <Lingli_Deng> sr-iov is not included in the dpacc gap analysis. 01[22:19] <Lingli_Deng> sorry for the confusion. 03[22:19] * Rabi ( has joined #opnfv-dpacc [22:19] <Magnus_> Thanks Subha [22:19] <keith-wiles> OK, great lets leave SR-IOV off until we see a need 01[22:19] <Lingli_Deng> OK 01[22:20] <Lingli_Deng> Anybody volunteer to work on openflow? [22:20] <Skip_> Why is OpenFlow in this list? I'm not sure why that's a dpacc issue 01[22:20] <Lingli_Deng> I saw proposals from Freescale and 6WIND mentioned openflow several times. 03[22:20] * VikramDham (4b31fe36@gateway/web/freenode/ip. has joined #opnfv-dpacc [22:21] <Skip_> unless the theory is to make sure the HW assists that you might map into for OpenFlow is what's being discussed [22:21] <Bob_> i too am questioning openflow [22:21] <keith-wiles> I would think only openstack integration is required. Maybe we can mark out openflow for now [22:21] <Skip_> that would be a very general list though and TBH not openflow specific. [22:21] <olli_> I think Openflow is orthogonal to how the VNF is implemented and accelerated. [22:22] <Skip_> I would tend to agree. [22:22] <olli_> And DPACC interested in the implementation and acceleration of VNF's. [22:22] <Srini_Intel> Openflow is one mechanism we thought initially to implement inline/fast-path acceleration for control-plane vNFs. [22:23] <Skip_> And to that point Olli, Openflow is just another feature/datapath mapping on top of those acceleration engines [22:23] <subha-fsl> @Lingli: we will get back on Openflow. If I recall correct, we had provided an implementation for virtio over openflow. [22:23] <collabot> subha-fsl: Error: "Lingli:" is not a valid command. [22:23] <olli_> AhI remember aomething. [22:23] <olli_> FSL mentioned at some time hwo to use OpenFlow to enable forwarding acceleration? [22:23] <subha-fsl> a possible implementation with virtio for openflow. [22:24] <Srini_Intel> Yes Skip. THat is what was the intention. Instead of having fast-path implementations for ADC, IPSec, Firewall, NAT indepedently, the thought is to implement OF paradigm based data-path in the bakend and program it to behave with various personalities dictated by local vNFs. [22:24] <Skip_> P4 would be the more interesting target if that was the intention. [22:24] <Skip_> This might be a rat-hole though… [22:24] <keith-wiles> Someone needs to define the need for openflow here and then we can decide 01[22:25] <Lingli_Deng> OK, I will mark openflow as TBD for later discussion after we had more clarification from Srini and Subha. [22:25] <Srini_Intel> Sure Keith. Since I proposed early on, I will take a shot at it. [22:25] <keith-wiles> I do not see a need at this time, but later maybe [22:25] <Skip_> Agreed Keith - if the discussion is that openflow or P4 might be the G-API, then I think that would be a reasonable discussion [22:26] <Srini_Intel> We can talk later. Idea is to define flow g-API from vNF. These flow G-API internally convert it to OF messages and program the OF backend. 01[22:26] <Lingli_Deng> Thanks. I will mark a follow-up action on later discussion. [22:27] <Skip_> ack Srini - if you want to chat offline I'd like to compare notes w/ you on this topic. [22:27] <Srini_Intel> SGW, PGW, Firewall, ADC kind of applications in vNFs can call into flow G-API to make the OF backend work as fast-path for them. [22:27] <keith-wiles> OK, Srini lets discuss the need here [22:27] <Srini_Intel> Sure Skip and Keith. I will touch base with you offline. 01[22:27] <Lingli_Deng> Get back to the task page [22:28] <keith-wiles> Srini can define the need and we can discuss this in a later meeting to see if we want to continue to define it for DPACC 01[22:28] <Lingli_Deng> Great. Thanks. Keith. 01[22:28] <Lingli_Deng> The second newly added work item is the test spec for dpacc 01[22:29] <Lingli_Deng> And it is highly related to the usecase doc [22:30] <keith-wiles> Are we doing functional testing or a use case testing? 01[22:30] <Lingli_Deng> I know that Srini is working on test spec for IPsec acceleration. [22:30] <keith-wiles> I would suggest a functional test only [22:30] <Srini_Intel> Hi Lingli, I did get much time in completing the test cases. But Bose and I are creating a slide deck on this. Will share it once we have enough meat in there. [22:31] <keith-wiles> IPSec is a feature or functional test and not a VNF use case correct [22:31] <Bob_> what do we consider the diference bet functest and use case test? I mean functest is straightforward. [22:31] <Srini_Intel> current test cases we are working on is mostly 'performance testing' keeping various use cases in mind. [22:32] <keith-wiles> Use case test to me is something like a firewall, … [22:32] <keith-wiles> Srini, that sounds reasonable to me [22:32] <keith-wiles> IPSec is a protocol and not an application or VNF [22:33] <VikramDham> Since dpacc is about acceleration it would help to get performance numbers [22:33] <keith-wiles> Agreeed [22:33] <Srini_Intel> Thanks Keith. Hopefully we would have something to share in few days. 03[22:34] * zhipeng (~zhipeng@ has joined #opnfv-dpacc 01[22:34] <Lingli_Deng> I would also like to know is anybody interested in working on other cases other than IPsec. [22:35] <keith-wiles> I suspect virtio will need a test at some point, is this correct Magnus [22:36] <Magnus_> Yes [22:37] <Magnus_> Lawfull intercept maybe :-) [22:37] <Srini_Intel> Keith and Magnus, I am hoping that IPSec use case will exercise virtio transport to great extent. So, we should be okay there, I think. Yes, if there are some virtio functions that are not exercised by IPSec-LA use case, then we need to identify them and define test cases, I guess. [22:37] <keith-wiles> Srini Agree 01[22:38] <Lingli_Deng> I dont' understand, Magnus. [22:38] <Magnus_> It is an app, but nothing we would like to implement [22:39] <Magnus_> Therefore the smiley [22:39] <keith-wiles> Allows law enforcement to grab packet, but this is a detail [22:39] <olli_> Sometimes they do unlawful intercept [22:39] <keith-wiles> :-) 01[22:39] <Lingli_Deng> :-) 01[22:40] <Lingli_Deng> We should look at the usecase doc now. [22:40] <olli_> Why do we need to test the full virtio? [22:40] <olli_> It supposedly exists and works. [22:40] <BobD> More generally, is lawful intercept basically a function of wire-speed packet capture? Say to a VF running on the server? [22:40] <keith-wiles> We need performance numbers on the crypto [22:40] <olli_> Our extensions, e.g. for crypto, should of course be tested [22:41] <Magnus_> Lawfull intercept is port replication plus decryption [22:41] <olli_> I assume that with LI, you should only capture the traffic from a specific user. Can't spy on everyone you know! [22:41] <Magnus_> Olli, yes that is probably true. [22:41] <keith-wiles> Lets not rat hole on LI [22:41] <Magnus_> Some filtering needed too then [22:41] <Magnus_> Yes, let us leave that topic [22:42] <NokMikeR> I was just about to say it happens regardless of implemention. "magically in the background" [22:42] <Magnus_> There are better apps 01[22:42] <Lingli_Deng> Keith, are you saying that we need a test on crypto? [22:42] <Srini_Intel> I am wondering the relation you are seeing between LI ( I like to call as tap monitoring) and virtio? Are you thinking that 'tap' requires some additional capabilities in virtio/vring transport? [22:42] <keith-wiles> We need to test the virtio-crypto and any changes we make to virtio along with performance 01[22:43] <Lingli_Deng> OK. Then let us go as Srini suggested. 01[22:44] <Lingli_Deng> @Srini for now, we have only considered performance testing. [22:44] <collabot> Lingli_Deng: Error: "Srini" is not a valid command. 01[22:45] <Lingli_Deng> Let me mark another follow-up item on funtional test. [22:46] <Srini_Intel> BTW, in Openstack, there is a project called 'tap-as-a-service'. This service programs (via taas agent) OVS to do port mirroring, does some kind of filtering and all. This mirrored port looks like any vport and hence I am thinking that there is no special virtio requirement. But, I would like to hear your views. [22:47] <Bob_> t 01[22:48] <Lingli_Deng> Guys, let us get back to [22:48] <Srini_Intel> Ok Lingli. Let us start with performance test cases. And see what else is missing and see whether we need to add any functional test category. Note that, performance tests donot work if some basic functionality does not work. That way, some basic functional tests are covered. 01[22:49] <Lingli_Deng> I made considerable changes to the usecases doc 01[22:49] <Lingli_Deng> Over which I would like to hear you comments [22:50] <keith-wiles> We have 11 minutes, what else [22:50] <Bob_> still looking for it. [22:50] <Bob_> where is the usa case doc? 01[22:50] <Lingli_Deng> Data Plane Acceleration Usecases 01[22:50] <Lingli_Deng> Table of Contents 01[22:50] <Lingli_Deng> Introduction 01[22:50] <Lingli_Deng> general introduction to dpacc project and usecases document 01[22:50] <Lingli_Deng> drafting in : 01[22:50] <Lingli_Deng> Acceleration Models 01[22:50] <Lingli_Deng> brief introduction to the three acceleration models: look-aside, offload (or inline) and external acceleration models 01[22:50] <Lingli_Deng> drafting in: 01[22:50] <Lingli_Deng> Usecases for IPsec acceleration 01[22:50] <Lingli_Deng> Targetting application 01[22:50] <Lingli_Deng> description of the targetted application scenario (e.g. small cell GW VNF) 01[22:50] <Lingli_Deng> performance metrics and benchmarking methodology 01[22:50] <Lingli_Deng> drafting in: 01[22:50] <Lingli_Deng> Usecase 1: Crypto offload 01[22:50] <Lingli_Deng> Usecase 2: Crypto acceleration by CPU instruction 01[22:50] <Lingli_Deng> Usecase 3: IPSec offload 01[22:50] <Lingli_Deng> Usecase 4: vNf offload 01[22:51] <Lingli_Deng> [22:51] <Bob_> I will need to review these with my team. [22:52] <BobD> I'm not sure about deleting Usecases like "lookaside acceleration". Seems like there's a fundamental difference between a lookaside use model vs an "in-line" IPsec model (i.e. a PCIe adapter with Enet ports on it and IPsec offload) [22:53] <Bob_> perhaps the intent is to move them to use case targets page? 01[22:54] <Lingli_Deng> no, they are covered by the acceleration models sections. 01[22:54] <Lingli_Deng> the target is an IPsec GW. 01[22:54] <Lingli_Deng> and there are different ways to accelerate its data plane 01[22:55] <Lingli_Deng> accelerate only the crypto, usecase1 01[22:55] <Lingli_Deng> and usecase2 01[22:55] <Lingli_Deng> accelerate IPSec, usecase3 01[22:56] <Lingli_Deng> and bypass the vNF in all, usecase4 [22:56] <BobD> Can you clarify more what is happening in usecase4? 01[22:56] <Lingli_Deng> for usecase1, look-aside or inline accelerators can be used 01[22:56] <Lingli_Deng> the same with usecase 3 01[22:58] <Lingli_Deng> @BobD It is what Srini described earlier, as to offload the data plane processing from the vNF [22:58] <collabot> Lingli_Deng: Error: "BobD" is not a valid command. 01[22:59] <Lingli_Deng> leaving it only the control plane to program the packet data path through various offload accelerators (components) [22:59] <BobD> OK, got it. [22:59] <Srini_Intel> Just to be clear : Use case 1 - Using look-aside crypto accelerator, Use case 2 - Using instruction level crypto accelerator such as AES-NI, USe case 3 - IPSec protocol level acceleration, but still look-aside (The PoC that is being worked out now) and USe case 4 - Inline/fast-path acceleration. 01[23:01] <Lingli_Deng> This is slight different from what I comprehend, Srini. But I believe we can have further discussions. [23:02] <keith-wiles> I have to attend another meeting and must leave, thanks everyone 01[23:02] <Lingli_Deng> Would this be a fair structure for the usecase doc? [23:02] <Srini_Intel> I need to go now. But my AR : Clarify OF usage for inline/fast-path acceleration. ANd I will continue to work with Bose and Vikram on performance setup and test cases. 01[23:02] <Lingli_Deng> Thank you Keith. 01[23:02] <Lingli_Deng> Thank you Srini. [23:02] <Bob_> thx 02[23:03] * Bob_ (18068276@gateway/web/freenode/ip. Quit (Quit: Page closed) 02[23:03] * Srini_Intel (86868b46@gateway/web/freenode/ip. Quit (Quit: Page closed) 02[23:03] * keith-wiles (c0373628@gateway/web/freenode/ip. Quit (Quit: Page closed) 02[23:03] * Bose (31cfbb83@gateway/web/freenode/ip. Quit (Quit: Page closed) 02[23:03] * Magnus_ (c0c69725@gateway/web/freenode/ip. Quit (Quit: Page closed) [23:03] <olli_> Talk to you next week Magnus! [23:03] <olli_> Bye 02[23:03] * olli_ (46232702@gateway/web/freenode/ip. Quit (Quit: Page closed) 01[23:03] <Lingli_Deng> Sorry we did not have time to cover framework. But I will send this to list and please provide feedback vie email. [23:04] <BobD> OK bye 03[23:07] * Rabi ( has left #opnfv-dpacc ("Quit") 02[23:10] * gg (6add96d9@gateway/web/freenode/ip. Quit (Ping timeout: 246 seconds) 02[23:10] * Mario_ (d98c608c@gateway/web/freenode/ip. Quit (Quit: Page closed) 02[23:14] * Skip_ (4066f906@gateway/web/freenode/ip. Quit (Quit: Page closed) 02[23:14] * VikramDham (4b31fe36@gateway/web/freenode/ip. Quit (Quit: Page closed) 02[23:15] * BobD (6c14796e@gateway/web/freenode/ip. Quit (Quit: Page closed) 02[23:15] * NokMikeR ( Quit (Quit: ircII EPIC4-2.10.5 – Are we there yet?) 02[23:20] * Kin-Yip_Liu_Cavi (62d2713f@gateway/web/freenode/ip. Quit (Ping timeout: 246 seconds) 03[23:22] * subha-fsl (6bdfd219@gateway/web/freenode/ip. has left #opnfv-dpacc 02[23:22] * Pradeep (32353ca0@gateway/web/freenode/ip. Quit (Quit: Page closed) 03[23:23] * Pradeep (32353ca0@gateway/web/freenode/ip. has joined #opnfv-dpacc 02[23:24] * Pradeep (32353ca0@gateway/web/freenode/ip. Quit (Client Quit)

dpacc/meeting_log_0923.txt · Last modified: 2015/09/24 07:27 by Lingli Deng