Re: [dpdk-dev] [PATCH v6 1/6] Move common functions in eal_thread.c

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Apr 21, 2015 at 12:28:24PM -0700, Ravi Kerur wrote:
> On Tue, Apr 21, 2015 at 7:25 AM, Bruce Richardson <
> bruce.richardson@intel.com> wrote:
> 
> > On Sat, Apr 18, 2015 at 12:43:06PM -0700, Ravi Kerur wrote:
> > > Changes in v6
> > > Remove RTE_EXEC_ENV_BSDAPP from eal_common_thread.c file.
> > > Add pthread_setname_np/pthread_set_name_np for Linux/FreeBSD
> > > respectively. Plan to use _getname_ in RTE_LOG when available.
> > > Use existing rte_get_systid() in RTE_LOG to print thread_id.
> >
> > Hi Ravi
> >
> > I think the change to add names to the threads might be better in an
> > existing
> > patch as it is separate from the change of making the code common.
> > [The code changes for the names also seems to have issues with it, as
> > described in comments below]
> >
> 
> Hi Bruce,
> 
> Thanks for your comments. Linux/FreeBSD has different APIs
> 
> pthread_setname_np and pthread_getname_np in Linux
> pthread_set_name_np in FreeBSD. FreeBSD has no "_get_name_" counterpart API.
> 
> API signatures are different as well. Current plan is to use
> "_setname_"/"_set_name_" appropriately and leave out "_getname_" until it
> is available in FreeBSD.
> 
> Are you suggesting to use separate patch for set/get pthread names?

Yes, I think that would be better. Have one patch just for moving the code
to a common location, then a second patch for adding in thread names since its
really a discrete unit of work. Apart from the bug with Linux vfio thread, the
idea and implementation looks really good, and something we would like to have.

/Bruce

> 
> More inline.
> 
> 
> > >
> > > Changes in v5
> > > Rebase to latest code.
> > >
> > > Changes in v4
> > > None
> > >
> > > Changes in v3
> > > Changed subject to be more explicit on file name inclusion.
> > >
> > > Changes in v2
> > > None
> > >
> > > Changes in v1
> > > eal_thread.c has minor differences between Linux and BSD, move
> > > entire file into common directory.
> > > Use RTE_EXEC_ENV_BSDAPP to differentiate on minor differences.
> > > Rename eal_thread.c to eal_common_thread.c
> > > Makefile changes to reflect file move and name change.
> > > Fix checkpatch warnings.
> > >
> > > Signed-off-by: Ravi Kerur <rkerur@gmail.com>
> > > ---
> > >  examples/vhost/main.c                              |  18 ++-
> > >  examples/vhost_xen/main.c                          |  18 ++-
> > >  lib/librte_eal/bsdapp/eal/Makefile                 |   2 +-
> > >  lib/librte_eal/bsdapp/eal/eal.c                    |   7 +
> > >  lib/librte_eal/bsdapp/eal/eal_thread.c             | 152
> > ---------------------
> > >  lib/librte_eal/common/eal_common_thread.c          | 147
> > +++++++++++++++++++-
> > >  lib/librte_eal/common/eal_thread.h                 |   5 +
> > >  lib/librte_eal/linuxapp/eal/Makefile               |   2 +
> > >  lib/librte_eal/linuxapp/eal/eal.c                  |  10 ++
> > >  lib/librte_eal/linuxapp/eal/eal_interrupts.c       |  11 ++
> > >  lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c |  22 ++-
> > >  lib/librte_eal/linuxapp/eal/eal_thread.c           | 152
> > +--------------------
> > >  lib/librte_eal/linuxapp/eal/eal_timer.c            |  15 +-
> > >  13 files changed, 250 insertions(+), 311 deletions(-)
> > >
> >
> > <<<snip>>>
> >
> > > --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
> > > +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
> > > @@ -34,6 +34,7 @@
> > >  #include <string.h>
> > >  #include <fcntl.h>
> > >  #include <sys/socket.h>
> > > +#include <pthread.h>
> > >
> > >  /* sys/un.h with __USE_MISC uses strlen, which is unsafe */
> > >  #ifdef __USE_MISC
> > > @@ -54,6 +55,7 @@
> > >
> > >  #include "eal_filesystem.h"
> > >  #include "eal_pci_init.h"
> > > +#include "eal_thread.h"
> > >
> > >  /**
> > >   * @file
> > > @@ -374,20 +376,36 @@ int
> > >  pci_vfio_mp_sync_setup(void)
> > >  {
> > >       int ret;
> > > +     char thread_name[RTE_THREAD_NAME_LEN];
> > >
> > >       if (vfio_mp_sync_socket_setup() < 0) {
> > >               RTE_LOG(ERR, EAL, "Failed to set up local socket!\n");
> > >               return -1;
> > >       }
> > >
> > > +     snprintf(thread_name, RTE_THREAD_NAME_LEN,
> > > +             "pci-vfio-mp-sync");
> >
> > This string is too long. According to the man page (Fedora Linux):
> > "The thread name is a meaningful C language string, whose length is
> > restricted to 16  charac‐
> >        ters, including the terminating null byte ('\0')."
> > I make the string 16+ null, i.e. 17 in total.
> >
> 
> My mistake, will fix it.
> 
> >
> > > +
> > >       ret = pthread_create(&socket_thread, NULL,
> > >                       pci_vfio_mp_sync_thread, NULL);
> > >       if (ret) {
> > > -             RTE_LOG(ERR, EAL, "Failed to create thread for
> > communication with "
> > > -                             "secondary processes!\n");
> > > +             RTE_LOG(ERR, EAL,
> > > +                     "Failed to create thread for communication with "
> > > +                     "secondary processes!\n");
> >
> > Should not split the error message string across multiple lines as it
> > breaks
> > git grep searches for the error message.
> >
> 
> Will fix it.
> 
> >
> > > +             close(mp_socket_fd);
> > > +             return -1;
> > > +     }
> > > +
> > > +     ret = pthread_setname_np(socket_thread, thread_name);
> > > +
> > > +     if (ret) {
> > > +             RTE_LOG(ERR, EAL,
> > > +                     "Failed to set thread name for "
> > > +                     "secondary processes!\n");
> > >               close(mp_socket_fd);
> > >               return -1;
> >
> > Do we really want to return with an error here. Right now I can't run any
> > apps
> > since I get an error on init of PCI - due to the name string being too
> > long for
> > Linux. (Things seem fine on BSD). Failing to name a thread doesn't seem to
> > be
> > a fatal error IMHO.
> >
> >
> When I coded understanding was that pthread _set_ APIs should not fail
> (excluding bugs whilst calling the API), since _get_ APIs will be called
> subsequently for logging and debugging it will not be of any help if I let
> program continue after _set_ failure. I will change the code to just log an
> error and return success.
> 
> Thanks,
> Ravi
> 
> 
> > Regards,
> > /Bruce
> >
> >