On Tue, 20 Dec 2016 12:23:25 +0530
Shreyansh Jain <shreyansh.j...@nxp.com> wrote:
> On Tuesday 20 December 2016 03:29 AM, Stephen Hemminger wrote:
> > Allow sufficicent space for UUID in string form (36+1).
> > Needed to use UUID with Hyper-V
> >
> > Signed-off-by: Stephen Hemminger <sthem...@microsoft.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 3 +++
> > lib/librte_ether/rte_ethdev.h | 6 +++++-
> > 2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index 2d17bc6e..b83f23a1 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -58,6 +58,9 @@ Deprecation Notices
> > ``port`` field, may be moved or removed as part of this mbuf work. A
> > ``timestamp`` will also be added.
> >
> > +* ethdev: for 17.02 the size of internal device name will be increased
> > + to 40 characters to allow for storing UUID.
> > +
> > * The mbuf flags PKT_RX_VLAN_PKT and PKT_RX_QINQ_PKT are deprecated and
> > are respectively replaced by PKT_RX_VLAN_STRIPPED and
> > PKT_RX_QINQ_STRIPPED, that are better described. The old flags and
> > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> > index 96781792..3c85e331 100644
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -1652,7 +1652,11 @@ struct rte_eth_dev_sriov {
> > };
> > #define RTE_ETH_DEV_SRIOV(dev) ((dev)->data->sriov)
> >
> > -#define RTE_ETH_NAME_MAX_LEN (32)
> > +/*
> > + * Internal identifier length
> > + * Sufficiently large to allow for UUID or PCI address
> > + */
> > +#define RTE_ETH_NAME_MAX_LEN 40
>
> Just to clarify my doubt: UUID is 36 byte long. So, 4 extra bytes are to
> keep the name length 4 byte aligned (along with one byte of \0)?
>
> Or, PCI based addressing can stretch 40 bytes?
UUID needs 37 bytes (36 + \0).
I just rounded up to next 4 byte boundary since it seemed like a good idea
expecting
that it might have to grow later.
Alternatively we could just get rid of NAME_MAX_LEN and allow arbitrary
length...
