>> Neil >> > Sorry for the delayed response, I've been on vacation. > >> Your modified copy of make has no bearing on the topic we are taking about >> customers using dpdk in standard distros right? >> > !? I really don't know what you're saying here. My only reason for > commenting > on my copy of make was to consider an explination for why make -j 0 might be > working for me, and not for you. I've since uninstalled and resinalled make > on > my system, and my copy now behaves as yours does > > But thats all really irrelevant. I don't know what you mean by this not > having > any bearing on the conversation since we're talking about customers using dpdk > in a distro. We're not really talking about that at all (if we were using > make > would be a moot point, since distro users tend to only use pre-compiled > binaries). Were talking about accelerating the build process when comparing > ABIs on two different dpdk versions, thats all.
Neil, (I am trying to not read your style of text as condescending and I will try to not do that as well) Not everyone uses DPDK from prebuilt libraries and we need to support them as well, correct? > >> Seems odd to me to send this out with 0 or lspci as it may fail because of >> no lspci and will fail on all Ubuntu systems. >> > Again, don't really understand what your saying. If you look at the patch, > neither of your assertions are true. With this patch and no other change, the > validate_abi script behaves exactly as it does now. The only thing I've done > is > add a check for the DPDK_MAKE_JOBS environment variable, and if its not set, > either: > > a) Set DPDK_MAKE_JOBS to 1 if lscpu doesn't exist on the system > b) Set DPDK_MAKE_JOBS to the number of online cpus if lscpu does exist > > All of that gets overridden if you manually set DPDK_MAKE_JOBS to something > else. > > seems pretty straightforward to me. At this point do we need to add yet another environment variable to get the correct behavior with DPDK. DPDK is very simple to build today and I worry we keep adding special variables to build DPDK. Can we just use a cleaner default, then adding more and more special build requirements? Adding this one is fine, but it also means the customer must read the docs to find this new variable. DPDK should be build able with the least amount of docs to read, then they can read the docs more later. Just looking at how the developer can get started building DPDK without RTFM problem. At some point they need to read the docs to possibly runs the examples, but to build DPDK should very simple IMO. > >> If we ship with 1 then why even bother the adding code and if I have to edit >> the file or some other method to get better compile performance then why >> bother as well. >> > Please stop and think for a minute. Why would you need to edit a file to > change > anything? If lscpu exists, then everything happens automatically. If it > doesn't you can still just run: > export DPDK_MAKE_JOBS=$BIGNUMBER; validate_abi.sh <args> Please do not add extra environment variable we would start to get to the point of having so many pre-build requirements it becomes the private knowledge to just build DPDK or a huge setup/RTFM problem. > > and it works fine. If ubuntu has some other utiilty besides lscpu to parse > cpu > counts, fine, we can add that in as a feature, but I don't see why that should > stop other, non-ubuntu systems from taking advantage of this. > >> Setting the value to some large number does not make any sense to me and if >> I have to edit file every time or maintain a patch just seems silly. >> > Goodness Keith, stop for just a minute with the editing the file train your > on. > Its an environment variable, you don't have to edit a file to change it. Yes Neil, you also need to stop an think about what you are placing on the developer to build DPDK. This one little problem is not the real issue to me, but a symptom of a growing problem in DPDK around how DPDK is build and the amount of knowledge or setup it requires to do this one simple task. > >> It just seems easier to set it to -j and not use lspci at all. This way we >> all win as I am not following your logic at all. >> > This doesn't even make any sense. If you set it to -j then you get make > issuing > jobs at the max rate make can issue them, which is potentially fine, but may > not > be what developers want in the event they don't want this script to monopolize > their system. The way its written now lets people get reasonable behavior in > most cases, and opt-in to the extreeme case should they desire. That makes > far > more sense to me, then just chewing up as much cpu as possible all the time. I only suggest -j as this would give the developer the best build performance without having to require lscpu or setting up yet another build environment variable. The lscpu command does not exist on all systems today and other non-Linux based systems in the future. The amount of gain with -j over with -j is a reasonable performance option, as for chewing up cpu performance for 20-50 seconds is not a problem IMO. Please look at the bigger picture and not just your way of building DPDK as most will have a standalone machine as a development platform (I would assume) and utilizing that machine to the fullest is not a problem (unless you need to get the last digit of PI in another process :-). I have DPDK building on Mac OS and lscpu does not exist for that system (I do not know about windows). Think about the future some and using -j just seems to have the least amount of requirements on the system, right? If the developer does not like the ?chew up all of my CPUs' problem then he can read the docs to set the environment variable, but I suspect that would not even happen in 99% of the cases. Keith
