Hi Nitin, inline...
> On 1 Jun 2018, at 15:23, Nitin Saxena <nitin.sax...@cavium.com> wrote: > > Hi Damjan, > > > It was hard to know that you have subset of patches hidden somewhere. > I wouldn't say patches are hidden. We are trying to fine tune dpdk-input > initially from our end first and later we will seek your expertise while > upstreaming. for me they were hidden. > > Typically it makes sense to discuss such kind of changes with person >who > > "maintains" the code before starting writing the code. > Agreed. However we prefer to do internal analysis/POC first before reaching > out to MAINTAINERS. That way we can better understand code review comments. Perfectly fine, but then don't put blame on us for not knowing that you are doing something internally... > > > Maybe, but sounds to me like we are still in guessing phase. > I wouldn't do any guess work with MAINTAINERS. > > > Maybe we even need different function for each ARM CPU core as they > > maybe have different memory subsystem and pipeline.... > This is what I am looking for. Is it ok to detect our hardware natively from > autoconf and append target specific macro to CFLAGS? And then separate > function for our target in dpdk/device/node.c? Sorry my multi-arch select > example was incorrect and that's not what I am looking at. Here I will be able to help when I get reasonable understanding what is the "big" plan. I don't want that we end up in 6 months with cavium patches, nxp patches, marvell patches, and so on.. > > > Is there an agreement between ARM vendors what is the targeted core > > you want to have code tuned for or you are simply tuning to whatever > > core Cavium uses? > I am trying to optimize Cavium's SOC. This question is in this regard only. > However efforts are going on optimizing Cortex cores as well by ARM community. What about agreeing on plan for optimising on all ARM cores, and then starting doing optimisation? > > Thanks, > Nitin > > On Friday 01 June 2018 01:55 AM, Damjan Marion wrote: >> inline... >> -- >> Damjan >>> On 31 May 2018, at 21:10, Saxena, Nitin <nitin.sax...@cavium.com >>> <mailto:nitin.sax...@cavium.com>> wrote: >>> >>> Hi Damjan, >>> >>> Answers inline. >>> >>> Thanks, >>> Nitin >>> >>>> On 01-Jun-2018, at 12:15 AM, Damjan Marion <dmarion.li...@gmail.com >>>> <mailto:dmarion.li...@gmail.com>> wrote: >>>> >>>> >>>> Dear Nitin, >>>> >>>> See inline…. >>>> >>>> >>>>> On 31 May 2018, at 19:59, Nitin Saxena <nitin.sax...@cavium.com >>>>> <mailto:nitin.sax...@cavium.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am working on optimising dpdk-input node (based on vpp v1804) for our >>>>> target. I am able to get performance improvements on our target but the >>>>> problem I am finding now are: >>>>> >>>>> 1) The dpdk-input code is completely changed on master branch from v1804. >>>> >>>> Why is this a problem? It was done with reason and for tangible benefit. >>> This is a problem for me as I can not apply my v1804 changes directly to >>> the master branch. I have to again rework on master branch and that’s why I >>> am not able to move to master branch or v1807 in future. >> It was hard to know that you have subset of patches hidden somewhere. >> Typically it makes sense to discuss such kind of changes with person who >> "maintains" the code before starting writing the code. >>>> >>>>> Not to mention the dpdk-input master branch code do not give better >>>>> numbers on our target as compared to v1804 >>>> >>>> Sad to hear that, good thing is, it gives better numbers on x86. >>> As I understand one dpdk_device_input function cannot be same for all >>> architectures because if the underlying micro-architecture is different, >>> the hot spots changes. >> Maybe, but sounds to me like we are still in guessing phase. >> Maybe we even need different function for each ARM CPU core as they maybe >> have different memory subsystem and pipeline.... >> Is there an agreement between ARM vendors what is the targeted core you want >> to have code tuned for or you are simply tuning to whatever core Cavium uses? >>> I have seen dpdk-input master branch changes and on a positive notes those >>> changes make sense however some codes are tuned for x86 specially Skylake. >>> I was looking for some kind of way to have mutiarch select function for >>> the Rx path, like the way it’s done for tx path. >> Not sure why do you need that, unless you are going to have code optimised >> for different CPU variants (i.e. Cortex-A53 and Cortex-A72) in the same >> binary. >>>> >>>>> 2) I don’t know the modular approach I should follow to merge my changes >>>>> as I have completely changed the quad loop handling and the prefetches >>>>> order in dpdk-input. >>>> >>>> I carefully tuned that code. It was multi day exercise and losing single >>>> clock/packet on x86 with additional modifications are not acceptable. >>>> Still I’m open for discussion how to address this problem. >>>> >>>>> >>>>> Note: I am far away from upstreaming the code currently as my >>>>> optimisation is still in progress. It will be better if I know the proper >>>>> way of doing it. >>>> >>>> I suggest that you don’t even start on working on upstreaming before we >>>> have deep understanding of what and why needs to be done and we are all in >>>> agreement. >>>> >>>>> >>>>> Thanks, >>>>> Nitin > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9493): https://lists.fd.io/g/vpp-dev/message/9493 View All Messages In Topic (6): https://lists.fd.io/g/vpp-dev/topic/20748102 Mute This Topic: https://lists.fd.io/mt/20748102/21656 New Topic: https://lists.fd.io/g/vpp-dev/post Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656 Group Home: https://lists.fd.io/g/vpp-dev Contact Group Owner: vpp-dev+ow...@lists.fd.io Terms of Service: https://lists.fd.io/static/tos Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub Email sent to: arch...@mail-archive.com -=-=-=-=-=-=-=-=-=-=-=-
