Setup for things like hugepages, driver mounts, etc. would be the responsibility of the wrapper script or other external configuration. I don't think that's the sort of thing you'd expect the ODP application to do. Note that this includes launching the app via sudo since DPDK seems to require that.
On Mon, Apr 27, 2015 at 1:17 PM, Maxim Uvarov <[email protected]> wrote: > On 04/27/15 19:20, Zoltan Kiss wrote: > >> >> >> On 24/04/15 20:45, Bill Fischofer wrote: >> >>> There are two aspects to consider: >>> >>> 1. Configuration info that is needed by the underlying ODP implementation >>> 2. ODP implementation-independent parameters that the application may >>> wish to specify >>> >>> The latter can be handled via arguments to odp_global_init(), however >>> the former should not be, as that would make the application >>> implementation-aware. ODP-defined environment variables would seem to >>> be a clean way to handle the former. So a wrapper script could export >>> an ODP_PLATFORM_PARAMS string that is retrieved by odp_global_init() and >>> passed to rte_eal_init() or other SDK being used by the implementation. >>> >> >> Sounds good. I guess it should be part of the API somehow, so I'm adding >> Petri and the main list. It would need at least some documentation in >> odp.git, something like this: >> >> "The implementation may require additional configuration which can be >> passed in the ODP_PLATFORM_PARAMS enviromental parameter. The application >> code don't have to be aware of this, but the user who runs this should fill >> this in if the implementation requires this" >> >> > For DPDK case you might be not needed that. If you need to pass a lot of > other dpdk specific steps to run odp-dpdk application. Like install network > drivers, switch them to dpdk mode, mount huge pages, specify dpdk port > names and etc. So that some env might be internal dpdk requirement. > > > Maxim. > > > >> >>> So rather than hard-coding this as ODP_DPDK_ARGS, why not make it more >>> general and let each implementation interpret the env variable >>> appropriately to the platform it's using? My guess is other platforms >>> would find this useful in providing their own configuration info. >>> >>> On Fri, Apr 24, 2015 at 2:25 PM, Zoltan Kiss <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Indeed, I'm also struggling to figure out how to make this work with >>> OVS: I think currently there is no sane way for the application to >>> know what kind of implementation is running underneath. >>> >>> On 24/04/15 20:17, Bill Fischofer wrote: >>> >>> The fact that DPDK is being used under the covers is intended to >>> be >>> transparent to the ODP application, so we should avoid having the >>> application do anything special for odp_global_init(). >>> Environment vars >>> may be a good means of communicating this info since that can be >>> set by >>> a launch script that wrappers the app without requiring changes >>> to the >>> app itself. Remember, many apps will be written for other >>> platforms and >>> will be porting to x86. Similarly, apps written for x86 need to >>> be >>> independent of DPDK so that they port easily to other ODP >>> platforms. >>> >>> On Fri, Apr 24, 2015 at 2:02 PM, Zoltan Kiss >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> wrote: >>> >>> >>> >>> On 15/04/15 14:07, Maxim Uvarov wrote: >>> >>> use ODP_DPDK_ARGS env variable to provide internal dpdk >>> things. >>> >>> Signed-off-by: Maxim Uvarov <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >>> --- >>> platform/linux-dpdk/odp_init.c | 81 >>> ++++++++++++++++++++++++++++++++---------- >>> 1 file changed, 62 insertions(+), 19 deletions(-) >>> >>> diff --git a/platform/linux-dpdk/odp_init.c >>> b/platform/linux-dpdk/odp_init.c >>> index fa10022..1f42976 100644 >>> --- a/platform/linux-dpdk/odp_init.c >>> +++ b/platform/linux-dpdk/odp_init.c >>> @@ -9,33 +9,76 @@ >>> #include <odp_debug.h> >>> #include <odp_packet_dpdk.h> >>> >>> + >>> +static int parse_dpdk_args(char *args, int *dst_argc, >>> char >>> ***dst_argv) { >>> + char *buf = strdup(args); >>> + int num = 1; >>> + char *delim; >>> + char **argv = calloc(num, sizeof (char *)); >>> + >>> + argv[0] = buf; >>> + >>> + while (1) { >>> + delim = strchr(argv[num - 1], ' '); >>> + if (delim == NULL) >>> + break; >>> + argv = realloc(argv, (num + 1) * sizeof (char >>> *)); >>> + argv[num] = delim + 1; >>> + *delim = 0; >>> + num++; >>> + } >>> + >>> + *dst_argc = num; >>> + *dst_argv = argv; >>> + >>> + return num; >>> +} >>> + >>> + >>> +static void print_dpdk_env_help(void) >>> +{ >>> + printf("use: export ODP_DPDK_ARGS=\"-c COREMASK >>> -n NUM >>> -- -p PORT\"\n"); >>> >>> >>> rte_eal_init() needs the first word to be a the log >>> facility name. >>> Either we should add it during our init, or tell it here to >>> the user >>> that before coremask there should be a word, or at least a >>> space. >>> >>> >>> + printf("-c COREMASK : A hexadecimal bitmask of >>> cores to >>> run on\n"); >>> + printf("-n NUM : Number of memory >>> channels\n"); >>> + printf("after -- specify standard DPDK >>> environment\n"); >>> +} >>> + >>> + >>> int odp_init_dpdk(void) >>> { >>> - int test_argc = 5; >>> - char *test_argv[6]; >>> - int core_count, i, num_cores = 0; >>> - char core_mask[8]; >>> + char **dpdk_argv; >>> + int dpdk_argc; >>> + char *env; >>> + int numargs; >>> + int core_mask, i; >>> >>> - core_count = odp_sys_core_count(); >>> - for (i = 0; i < core_count; i++) >>> - num_cores += (0x1 << i); >>> - sprintf(core_mask, "%x", num_cores); >>> + env = getenv("ODP_DPDK_ARGS"); >>> + if (env == NULL) { >>> + print_dpdk_env_help(); >>> + ODP_ERR("ODP_DPDK_ARGS has to be >>> exported"); >>> + return -1; >>> + } >>> >>> - test_argv[0] = malloc(sizeof("odp_dpdk")); >>> - strcpy(test_argv[0], "odp_dpdk"); >>> - test_argv[1] = malloc(sizeof("-c")); >>> - strcpy(test_argv[1], "-c"); >>> - test_argv[2] = malloc(sizeof(core_mask)); >>> - strcpy(test_argv[2], core_mask); >>> - test_argv[3] = malloc(sizeof("-n")); >>> - strcpy(test_argv[3], "-n"); >>> - test_argv[4] = malloc(sizeof("3")); >>> - strcpy(test_argv[4], "3"); >>> + for (i = 0, core_mask = 0; i < >>> odp_sys_core_count(); i++) >>> + core_mask += (0x1 << i); >>> >>> - if (rte_eal_init(test_argc, (char **)test_argv) >>> < 0) { >>> + char *s= calloc(1, strlen(env) + >>> strlen("progname -c ") + >>> + sizeof(core_mask) + 1); >>> + sprintf(s, "progname -c %x %s", core_mask, env); >>> + >>> + numargs = parse_dpdk_args(s, &dpdk_argc, >>> &dpdk_argv); >>> + while (numargs) { >>> + int i = dpdk_argc - numargs; >>> + ODP_DBG("arg[%d]: %s\n", i, >>> dpdk_argv[i]); >>> + numargs--; >>> + }; >>> + fflush(stdout); >>> + >>> + if (rte_eal_init(dpdk_argc, dpdk_argv) < 0) { >>> ODP_ERR("Cannot init the Intel DPDK >>> EAL!"); >>> return -1; >>> } >>> + ODP_DBG("rte_eal_init OK\n"); >>> >>> if (rte_eal_pci_probe() < 0) { >>> ODP_ERR("Cannot probe PCI\n"); >>> >>> _______________________________________________ >>> lng-odp-dpdk mailing list >>> [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> https://lists.linaro.org/mailman/listinfo/lng-odp-dpdk >>> >>> >>> >>> >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
