DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Cc: Hemant Agrawal <hemant.agrawal@nxp.com>,
	"Xu, Rosen" <rosen.xu@intel.com>,  "dev@dpdk.org" <dev@dpdk.org>,
	"Trahe, Fiona" <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [PATCH v1 1/5] rawdev: introduce raw device library support
Date: Fri, 12 Jan 2018 19:35:18 +0000	[thread overview]
Message-ID: <348A99DA5F5B7549AA880327E580B435892F64D2@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <4adc1036-6d91-a550-a80a-37347dae184c@nxp.com>

Hi Shreyansh,

/// snip ///
> > [Fiona] Yes. I'm probably overcomplicating it.
> > I was considering scanned devices and e.g. a case where 2 PMDs inadvertently pick the same name.
> > One idea would be each driver would register a type string with the lib layer and
> > all its device names must start with this, thus ensuring that each device name is unique.
> > With the vdev devices the application can ensure device names are unique.
> > A driver would not be allowed to use a name starting with a string which another PMD had already
> registered.
> >
> > This would allow looser coupling between the applications and the PMDs, as applications
> > would not need to know the exact name format of device name, just know the type it wants to use
> > and search for all devices with names starting with that string.
> > But I'm probably anticipating issues which wouldn't happen in real world applications.
> > i.e. though there may be many PMDs and applications in the dpdk codebase using this lib in future,
> > it's likely only a small number will be compiled into any build so such name clashes are unlikely to occur.
> > And the applications must be tightly coupled with the PMD anyway to make use of the device, so
> > that's probably not a concern either.
> I agree with the last line that applications have to be tightly coupled
> with PMD in this case. That defines (or prevents defining) a lot of
> semantics.
> 
> While creating the patches, even I was thinking of standardizing the
> naming (taking hint from some of Gaetan's work on devargs) but I
> couldn't think of a policy which can be enforced only by the rawlib.
> 
> I concur with you that conflicting naming in a real world scenario is
> theoretically possible, irrespective of how rare it might be.
> 
> I suggest that we continue as is and expand this in future when we have
> more clarity or even some real-world application samples.
> 
> You have any objections to this?
> 
No, I agree, this is the best approach.

Fiona


  reply	other threads:[~2018-01-12 19:35 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-02 12:57 [dpdk-dev] [PATCH v1 0/5] Introduce generic 'rawdevice' support Shreyansh Jain
2018-01-02 12:57 ` [dpdk-dev] [PATCH v1 1/5] rawdev: introduce raw device library support Shreyansh Jain
2018-01-06 13:40   ` Trahe, Fiona
2018-01-08 14:09     ` Shreyansh Jain
2018-01-08 14:51       ` Trahe, Fiona
2018-01-12 15:00         ` Shreyansh Jain
2018-01-12 19:35           ` Trahe, Fiona [this message]
2018-01-14 22:42   ` Thomas Monjalon
2018-01-14 22:50   ` Thomas Monjalon
2018-01-02 12:57 ` [dpdk-dev] [PATCH v1 2/5] config: enable compilation of rawdev library Shreyansh Jain
2018-01-14 22:50   ` Thomas Monjalon
2018-01-02 12:57 ` [dpdk-dev] [PATCH v1 3/5] drivers/raw: introduce skeleton rawdev driver Shreyansh Jain
2018-01-14 22:54   ` Thomas Monjalon
2018-01-16 10:21     ` Shreyansh Jain
2018-01-16 10:34       ` Thomas Monjalon
2018-01-02 12:57 ` [dpdk-dev] [PATCH v1 4/5] config: enable compilation of rawdev skeleton driver Shreyansh Jain
2018-01-14 22:55   ` Thomas Monjalon
2018-01-02 12:57 ` [dpdk-dev] [PATCH v1 5/5] test: support for rawdev testcases Shreyansh Jain
2018-01-14 22:58   ` Thomas Monjalon
2018-01-16 10:07     ` Shreyansh Jain
2018-01-16 10:32       ` Thomas Monjalon
2018-01-14 23:00 ` [dpdk-dev] [PATCH v1 0/5] Introduce generic 'rawdevice' support Thomas Monjalon
2018-01-15  5:30   ` Shreyansh Jain
2018-01-23 13:59 ` [dpdk-dev] [PATCH v2 00/10] " Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 01/10] rawdev: introduce raw device library support Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 02/10] rawdev: add attribute get and set support Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 03/10] rawdev: add buffer stream IO support Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 04/10] rawdev: support for extended stats Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 05/10] rawdev: support for firmware management Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 06/10] rawdev: add self test support Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 07/10] drivers/raw: introduce skeleton rawdev driver Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 08/10] drivers/raw: support for rawdev testcases Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 09/10] test: enable rawdev skeleton test Shreyansh Jain
2018-01-23 13:59   ` [dpdk-dev] [PATCH v2 10/10] maintainers: claim ownership of rawdev Shreyansh Jain
2018-01-25 22:21   ` [dpdk-dev] [PATCH v2 00/10] Introduce generic 'rawdevice' support Thomas Monjalon
2018-01-29 23:49     ` Thomas Monjalon
2018-01-30  6:31       ` Shreyansh Jain
2018-01-30 14:56   ` [dpdk-dev] [PATCH v3 00/11] " Shreyansh Jain
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 01/11] rawdev: introduce raw device library support Shreyansh Jain
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 02/11] rawdev: add attribute get and set support Shreyansh Jain
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 03/11] rawdev: add buffer stream IO support Shreyansh Jain
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 04/11] rawdev: support for extended stats Shreyansh Jain
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 05/11] rawdev: support for firmware management Shreyansh Jain
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 06/11] rawdev: add self test support Shreyansh Jain
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 07/11] drivers/raw: introduce skeleton rawdev driver Shreyansh Jain
2018-01-30 16:48       ` Thomas Monjalon
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 08/11] drivers/raw: support for rawdev testcases Shreyansh Jain
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 09/11] test: enable rawdev skeleton test Shreyansh Jain
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 10/11] maintainers: claim ownership of rawdev Shreyansh Jain
2018-01-30 16:50       ` Thomas Monjalon
2018-01-30 14:57     ` [dpdk-dev] [PATCH v3 11/11] doc: add rawdev library page Shreyansh Jain
2018-01-30 16:55     ` [dpdk-dev] [PATCH v3 00/11] Introduce generic 'rawdevice' support Thomas Monjalon
2018-01-31  9:13     ` [dpdk-dev] [PATCH v4 00/10] " Shreyansh Jain
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 01/10] rawdev: introduce raw device library support Shreyansh Jain
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 02/10] rawdev: add attribute get and set support Shreyansh Jain
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 03/10] rawdev: add buffer stream IO support Shreyansh Jain
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 04/10] rawdev: support for extended stats Shreyansh Jain
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 05/10] rawdev: support for firmware management Shreyansh Jain
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 06/10] rawdev: add self test support Shreyansh Jain
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 07/10] drivers/raw: introduce skeleton rawdev driver Shreyansh Jain
2018-01-31 13:20         ` Thomas Monjalon
2018-01-31 13:31           ` Thomas Monjalon
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 08/10] drivers/raw: support for rawdev testcases Shreyansh Jain
2018-01-31 14:01         ` Thomas Monjalon
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 09/10] test: enable rawdev skeleton test Shreyansh Jain
2018-01-31  9:13       ` [dpdk-dev] [PATCH v4 10/10] doc: add rawdev library page and support Doxygen Shreyansh Jain
2018-01-31 14:45       ` [dpdk-dev] [PATCH v4 00/10] Introduce generic 'rawdevice' support Thomas Monjalon

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=348A99DA5F5B7549AA880327E580B435892F64D2@IRSMSX101.ger.corp.intel.com \
    --to=fiona.trahe@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=rosen.xu@intel.com \
    --cc=shreyansh.jain@nxp.com \
    /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).