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.198.175.68.38) Quit (Ping timeout: 246 seconds)
03[21:46] * mpaolino (~Michele@host39-230-dynamic.59-82-r.retail.telecomitalia.it) has joined #opnfv-dpacc
03[21:55] * keith-wiles (c0373628@gateway/web/freenode/ip.192.55.54.40) 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.192.198.151.37) 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.98.210.113.63) 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.99.241.148.227) 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.107.223.210.25) 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.108.20.121.110) 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.70.35.39.2) has joined #opnfv-dpacc
03[22:05] * mikruots (c2fb77c6@gateway/web/freenode/ip.194.251.119.198) has joined #opnfv-dpacc
01[22:05] <Lingli_Deng> Hi guys, shall we start now?
03[22:06] * Bob_ (18068276@gateway/web/freenode/ip.24.6.130.118) has joined #opnfv-dpacc
[22:06] <keith-wiles> OK
03[22:06] * Pradeep (32353ca0@gateway/web/freenode/ip.50.53.60.160) 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.70.35.39.2) has joined #opnfv-dpacc
[22:06] <Bob_> sorry i was late
03[22:06] * Bose (31cfbb83@gateway/web/freenode/ip.49.207.187.131) 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> https://etherpad.opnfv.org/p/dpacc-tasks
01[22:07] <Lingli_Deng> Hi Bob, Bob
[22:08] <Bob_> hi
01[22:08] <Lingli_Deng> Would everybody go to https://etherpad.opnfv.org/p/dpacc-tasks
[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.70.35.39.2) 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.106.221.150.217) 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 https://etherpad.opnfv.org/p/dpacc_gap
03[22:11] * lab_ (~lab@dsl-hkibrasgw4-54f857-89.dhcp.inet.fi) 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: https://etherpad.opnfv.org/p/dpacc_framework_gap_appdpdk
01[22:12] <Lingli_Deng> odp: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_appodp
01[22:12] <Lingli_Deng> guest-host interfaces
01[22:12] <Lingli_Deng> virtio: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_virtio
01[22:12] <Lingli_Deng> sr-iov: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_sriov
01[22:12] <Lingli_Deng> mgmt interfaces/components
01[22:12] <Lingli_Deng> openflow: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_openflow
01[22:12] <Lingli_Deng> openstack: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_openstack
03[22:12] * Skip_ (4066f906@gateway/web/freenode/ip.64.102.249.6) has joined #opnfv-dpacc
03[22:12] * Mario_ (d98c608c@gateway/web/freenode/ip.217.140.96.140) has joined #opnfv-dpacc
03[22:12] * Srini_Intel (86868b46@gateway/web/freenode/ip.134.134.139.70) 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> https://etherpad.opnfv.org/p/dpacc_gap
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: https://etherpad.opnfv.org/p/dpacc_framework_gap_appdpdk
01[22:14] <Lingli_Deng> odp: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_appodp
01[22:14] <Lingli_Deng> guest-host interfaces
01[22:14] <Lingli_Deng> virtio: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_virtio
01[22:14] <Lingli_Deng> sr-iov: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_sriov
01[22:14] <Lingli_Deng> mgmt interfaces/components
01[22:14] <Lingli_Deng> openflow: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_openflow
01[22:14] <Lingli_Deng> openstack: drafting in: https://etherpad.opnfv.org/p/dpacc_framework_gap_openstack
[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 (~androirc@host-92-30-34-250.as13285.net) 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.75.49.254.54) 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 https://etherpad.opnfv.org/p/dpacc-tasks
[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@223.73.110.169) 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 https://etherpad.opnfv.org/p/dpacc-tasks
[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 :https://etherpad.opnfv.org/p/dpacc_usecase_intro
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: https://etherpad.opnfv.org/p/dpacc_usecase_models
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: https://etherpad.opnfv.org/p/dpacc_usecase_target
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> https://etherpad.opnfv.org/p/dpacc_usecases
[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.24.6.130.118) Quit (Quit: Page closed)
02[23:03] * Srini_Intel (86868b46@gateway/web/freenode/ip.134.134.139.70) Quit (Quit: Page closed)
02[23:03] * keith-wiles (c0373628@gateway/web/freenode/ip.192.55.54.40) Quit (Quit: Page closed)
02[23:03] * Bose (31cfbb83@gateway/web/freenode/ip.49.207.187.131) Quit (Quit: Page closed)
02[23:03] * Magnus_ (c0c69725@gateway/web/freenode/ip.192.198.151.37) 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.70.35.39.2) 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 (~androirc@host-92-30-34-250.as13285.net) has left #opnfv-dpacc ("Quit")
02[23:10] * gg (6add96d9@gateway/web/freenode/ip.106.221.150.217) Quit (Ping timeout: 246 seconds)
02[23:10] * Mario_ (d98c608c@gateway/web/freenode/ip.217.140.96.140) Quit (Quit: Page closed)
02[23:14] * Skip_ (4066f906@gateway/web/freenode/ip.64.102.249.6) Quit (Quit: Page closed)
02[23:14] * VikramDham (4b31fe36@gateway/web/freenode/ip.75.49.254.54) Quit (Quit: Page closed)
02[23:15] * BobD (6c14796e@gateway/web/freenode/ip.108.20.121.110) Quit (Quit: Page closed)
02[23:15] * NokMikeR (~lab@dsl-hkibrasgw4-54f857-89.dhcp.inet.fi) Quit (Quit: ircII EPIC4-2.10.5 – Are we there yet?)
02[23:20] * Kin-Yip_Liu_Cavi (62d2713f@gateway/web/freenode/ip.98.210.113.63) Quit (Ping timeout: 246 seconds)
03[23:22] * subha-fsl (6bdfd219@gateway/web/freenode/ip.107.223.210.25) has left #opnfv-dpacc
02[23:22] * Pradeep (32353ca0@gateway/web/freenode/ip.50.53.60.160) Quit (Quit: Page closed)
03[23:23] * Pradeep (32353ca0@gateway/web/freenode/ip.50.53.60.160) has joined #opnfv-dpacc
02[23:24] * Pradeep (32353ca0@gateway/web/freenode/ip.50.53.60.160) Quit (Client Quit)
