From: Ravi Kerur <rkerur@gmail.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v6 1/6] Move common functions in eal_thread.c
Date: Wed, 22 Apr 2015 08:39:19 -0700 [thread overview]
Message-ID: <CAFb4SLBU1autF5COcj=44yyginRu8eJNWxypa=a34m9CciRmog@mail.gmail.com> (raw)
In-Reply-To: <20150422090311.GA5652@bricha3-MOBL3>
On Wed, Apr 22, 2015 at 2:03 AM, Bruce Richardson <
bruce.richardson@intel.com> wrote:
> 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.
>
Thanks Bruce. I will take care of removing it from EAL common patch series
and send out a separate patch for this.
>
> /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
> > >
> > >
>
prev parent reply other threads:[~2015-04-22 15:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-18 19:42 [dpdk-dev] [PATCH v6 0/6] Move common functions in EAL Ravi Kerur
2015-04-18 19:43 ` [dpdk-dev] [PATCH v6 1/6] Move common functions in eal_thread.c Ravi Kerur
2015-04-18 19:43 ` [dpdk-dev] [PATCH v6 2/6] Move common functions in eal.c Ravi Kerur
2015-04-21 14:36 ` Bruce Richardson
2015-04-21 19:13 ` Ravi Kerur
2015-04-22 9:21 ` Bruce Richardson
2015-04-22 15:37 ` Ravi Kerur
2015-04-18 19:43 ` [dpdk-dev] [PATCH v6 3/6] Move common functions in eal_lcore.c Ravi Kerur
2015-04-18 19:43 ` [dpdk-dev] [PATCH v6 4/6] Move common functions in eal_timer.c Ravi Kerur
2015-04-18 19:43 ` [dpdk-dev] [PATCH v6 5/6] Move common functions in eal_memory.c Ravi Kerur
2015-04-18 19:43 ` [dpdk-dev] [PATCH v6 6/6] Move common functions in eal_pci.c Ravi Kerur
2015-04-21 14:25 ` [dpdk-dev] [PATCH v6 1/6] Move common functions in eal_thread.c Bruce Richardson
2015-04-21 19:28 ` Ravi Kerur
2015-04-22 9:03 ` Bruce Richardson
2015-04-22 15:39 ` Ravi Kerur [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFb4SLBU1autF5COcj=44yyginRu8eJNWxypa=a34m9CciRmog@mail.gmail.com' \
--to=rkerur@gmail.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).