[dpdk-dev] [PATCH v1] maintainers: update documentation maintainers

[Butler, Siobhan A]

> -Original Message-
> From: Mcnamara, John
> Sent: Tuesday, November 8, 2016 9:32 AM
> To: dev at dpdk.org
> Cc: Mcnamara, John 
> Subject: [PATCH v1] maintainers: update documentation maintainers
> 
> Signed-off-by: John McNamara 
> ---
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS index ba12d1b..11de99c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -43,7 +43,6 @@ M: maintainers at dpdk.org
> 
>  Documentation (with overlaps)
>  -
> -M: Siobhan Butler 
>  M: John McNamara 
>  F: README
>  F: doc/
> --
> 2.7.4

Aked-by: Siobhan Butler 

[dpdk-dev] Last few spaces & Agenda released for DPDK Userspace Summit 2016

[Butler, Siobhan A]

Hi all,
There are just a few spaces left at this year's DPDK Userspace Summit, if you 
want to attend please register at www.dpdksummit.com 
where you can review the agenda for the two days of the event. Thanks to those 
who have already registered, but again if you can't make it please let us know!

Look forward to seeing you in Dublin!
Siobh?n

[dpdk-dev] DPDK Userspace Summit Dublin 2016 (October 20th & 21st)

[Butler, Siobhan A]

Dear Community,
I am delighted to let you know our registration for this year's summit is very 
close to capacity already! If you are intending on attending please register 
(www.dpdksummit.com) as soon as possible to avoid 
disappointment.
If you have registered and cannot attend we would be very grateful if you could 
let us know so that we can fill the space.
Very excited to see you in October,
Siobh?n

[dpdk-dev] Reminder: Registration for DPDK Userspace Summit 2016 - Dublin Ireland IS NOW OPEN

[Butler, Siobhan A]

Hi all,

Just a reminder to register now for DPDK Userspace Summit 2016! Call for 
submissions (presentations, lightning talks, or discussion topics) has been 
extended to September 1st - please send your proposal to dpdk.summit at 
intel.com or if you have any queries feel free 
to email me at Siobhan.a.butler at intel.com.


Following the success of DPDK Userspace Summit last October in Dublin we are 
delighted to invite you back to Userspace Summit October 2016! The two day, 
developer centric event will be run in a similar format to last year (see 
www.dpdksummit.com for past agenda and videos) and 
we hope that we will have many returning guests and many new guests at this 
event. Registration is now open at 
www.dpdksummit.com, get you're registration in early 
as places are limited to maintain the discussion and collaboration at the event 
again this year. If you have topic ideas or would like to put yourself forward 
as a speaker please don't hesitate to contact me (siobhan.a.butler at 
intel.com) or Tim O'Driscoll 
(tim.odriscoll at intel.com)
Can't wait to see you there!!

DPDK Userspace Summit 2016:

The Clayton Hotel
Ballsbridge,
 Dublin, Ireland
October 20th - 21st, 2016
9:00am - 5:30pm

Many Thanks,
Siobhan

P.S. there will be DPDKake :)

[dpdk-dev] Announcement: Registration for DPDK Userspace Summit 2016 - Dublin Ireland IS NOW OPEN

[Butler, Siobhan A]

Hi all,

Congratulations on a successful DPDK 16.07 release! It is wonderful to see the 
community continue to grow and develop with each release.

Following the success of DPDK Userspace Summit last October in Dublin we are 
delighted to invite you back to Userspace Summit October 2016! The two day, 
developer centric event will be run in a similar format to last year (see 
www.dpdksummit.com for past agenda and videos) and 
we hope that we will have many returning guests and many new guests at this 
event. Registration is now open at 
www.dpdksummit.com, get you're registration in early 
as places are limited to maintain the discussion and collaboration at the event 
again this year. If you have topic ideas or would like to put yourself forward 
as a speaker please don't hesitate to contact me (siobhan.a.butler at 
intel.com) or Tim O'Driscoll 
(tim.odriscoll at intel.com)
Can't wait to see you there!!

DPDK Userspace Summit 2016:

The Clayton Hotel
Ballsbridge,
 Dublin, Ireland
October 20th - 21st, 2016
9:00am - 5:30pm

Many Thanks,
Siobhan

P.S. there will be DPDKake :)

[dpdk-dev] Recap of DPDK Userspace 2015

[Butler, Siobhan A]

Hi all,
Thanks to everyone who responded to the survey of DPDK Userspace 2015 
https://www.surveymonkey.com/r/6TN65VF.
You can now view the videos of the presentations and lightning talks  from the 
conference at https://dpdksummit.com/us/en/past-events!!
Thanks
Siobh?n

[dpdk-dev] DPDK Userspace 2015 - THIS WEEK

[Butler, Siobhan A]

Hi all,
We can't wait to meet all of you who will travel to DPDK Userspace 2015 in 
Dublin this week!
The latest agenda is available on https://dpdksummit.com/us/en/userspace2015/
The mailing list has been busy so there will be lots to discuss, if you have 
any queries please let me know.
See you there,
Siobh?n

[dpdk-dev] DPDK.org Community Call - Sept 24 - Discuss Growth, Improvements

[Butler, Siobhan A]

Super discussions today on the community call. Looking forward to continuing 
the open and honest dialogue in Dublin in two weeks' time.
Don't forget if you have registered for DPDK Userspace 2015 and can't make it 
please let me know as we have a waiting list.
Thanks
Siobh?n 

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of St
> Leger, Jim
> Sent: Thursday, September 24, 2015 12:56 AM
> To: Dave Neary; dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK.org Community Call - Sept 24 -
> Discuss Growth, Improvements
> 
> This call is aimed to get more open dialogue in the
> community.  Yes, the slot at DPDK Userspace should delve
> deeper into the subject. But rather than wait it has been
> desired by several people to get some discussion going now
> ahead of the Dublin gathering.  I hope the community can
> start the conversation now and then tee up some areas to dig
> into deeper when people are face-to-face in Dublin (those
> who can make it anyway.) And of course if people aren't going
> to Dublin this is an easy path to be heard and contribute to the
> discussion.
> I hope that helps.
> Jim
> 
> -Original Message-
> From: Dave Neary [mailto:dneary at redhat.com]
> Sent: Wednesday, September 23, 2015 2:00 PM
> To: St Leger, Jim; dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK.org Community Call - Sept 24 -
> Discuss Growth, Improvements
> 
> Hi Jim,
> 
> I see that there is a session loosely aligned with the agenda
> below on the agenda for DPDK Userspace in Dublin:
> https://dpdksummit.com/us/en/userspace2015 (current
> speaker is TBC).
> Will this call serve as a preparation call for that face to face
> meeting? In which case, is this the best opportunity that
> people who cannot travel to Dublin will have to make any
> concerns/proposals known so that they can be discussed
> there?
> 
> Thanks,
> Dave.
> 
> On 09/22/2015 03:14 AM, St Leger, Jim wrote:
> > I am going to host a community call on Thursday Sept 24 at
> 7:00am Pacific daylight time.  The conference call dial-in info
> via GoToMeeting is pasted below.  Here is the background and
> objective of the discussion.
> >
> > The DPDK community continues to grow.  Here are some
> stats on the 2.1 release from August 17th:
> > => 827 commits. A growth of ~50% over the 2.0 release.
> > => 82 individual committers. A growth of ~33% over the 2.0
> release.
> > The number of companies contributing has also continued to
> grow.
> >
> > There is a strong desire to continue to grow and solidify the
> community. But the growth brings up the question of how the
> community is structured to scale.   Additionally, there are
> many private DPDK repositories across the industry (e.g. ARM
> ports, for example.)  There are a myriad of reasons why
> companies have elected to keep their DPDK code and ports
> private versus put them into the DPDK.org community. We as
> a community need to understand and explore these reasons
> and work towards enabling inclusion.
> >
> > During this gathering I'd like to bring together the DPDK
> community including:
> > a) the DPDK code contributors,
> > b) the consumers of DPDK downstream (VNF vendors, etc.),
> > c) private branch DPDK creators/consumers, and
> > d) anyone else interested in the growth and future of the
> DPDK open source software project.
> >
> > The call will focus on two topics:
> >
> > 1)Structure for growth:
> >
> > Do we have the community practices, policies, and
> procedures in place to allow us to continue to grow on our
> current trajectory?
> >
> >
> >
> > 2)Gaps Limiting Participation:
> >
> > What gaps do companies who would like to
> participate/contribute to DPDK.org see?
> >
> > What changes would they like to see made to improve the
> project?
> >
> > I hope people can attend AND that they will join and speak
> up and be heard. The success and growth of the community
> depends on YOU!
> >
> > Thanks,
> > Jim
> > =
> > DPDK Community Call
> >
> > Thu, Sep 24, 2015 3:00 PM - 4:00 PM GMT Daylight Time
> Please join my
> > meeting from your computer, tablet or smartphone.
> > https://global.gotomeeting.com/join/766709085
> >
> > You can also dial in using your phone.
> >
> > Access Code: 766-709-085
> > Dial-in phone numbers
> > United States : +1 (312) 757-3117
> > Australia : +61 2 8355 1031
> > Austria : +43 (0) 7 2088 1033
> > Belgium : +32 (0) 28 93 7001
> > Canada : +1 (647) 497-9371
> > Denmark : +45 (0) 69 91 89 33
> > Finland : +358 (0) 942 41 5770
> > France : +33 (0) 170 950 585
> > Germany : +49 (0) 692 5736 7303
> > Ireland : +353 (0) 19 030 050
> > Italy : +39 0 693 38 75 50
> > Netherlands : +31 (0) 208 080 208
> > New Zealand : +64 9 925 0481
> > Norway : +47 21 54 82 21
> > Spain : +34 911 82 9890
> > Sweden : +46 (0) 853 527 817
> > Switzerland : +41 (0) 435 0167 65
> > United Kingdom : +44 (0) 20 3713 5010
> >
> >
> 
> --
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red 

[dpdk-dev] [dpdk-dev,3/3] acl: mark deprecated functions

[Butler, Siobhan A]

Hi Stephen
Would you be able to patch in some notices to the Depreciation section of the 
documentation for these changes?
Thanks
Siobhan

[dpdk-dev] Reminder to Register for DPDK Summit August 17th

[Butler, Siobhan A]

Hi all,

Just a little reminder that there is still time to register for DPDK Summit 
2015 - San Francisco, August 17th.
Go to www.dpdksummit.com to register for DPDK Summit 
and view upcoming events.

Siobhan

[dpdk-dev] Register for Userspace 2015

[Butler, Siobhan A]

Hi all

Just a gentle reminder to register your attendance for DPDK Userspace 2015 at 
https://dpdksummit.com/us/en/userspace2015 as places are filling up and are 
strictly limited :)

Thanks
Siobhan

[dpdk-dev] Register now for DPDK Userspace 2015!

[Butler, Siobhan A]

Hi all,

It is with great excitement and delight that I welcome you, the DPDK.org 
development community, to register your attendance for DPDK Userspace 2015 - 
October 8th and 9th 2015, Ballsbridge Hotel, Pembroke Road, Dublin 4, Ireland. 
Userspace 2015 is a developer forum which will focus on the elements of DPDK 
which are most pertinent to the open source software community members. This 
two day, immersive session will be highly interactive with discussions on the 
latest features and upcoming changes to DPDK. Most of the key DPDK 
authors/contributors will be present, so the event provides an opportunity to 
network, discuss issues, and help to guide the future direction of the project. 
The event follows LinuxCon EMEA & CloudOpen, October 5-7 also hosted in Dublin. 
Join in to add your voice to the future of DPDK. 

Places are very limited so please register to attend as early as possible.

Register today at: https://dpdksummit.com/us/en/userspace2015

Many thanks and look forward to seeing you in October!
Siobhan

[dpdk-dev] dev@DPDK Hackathon Proposal

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, May 19, 2015 3:20 PM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] dev at DPDK Hackathon Proposal
> 
> On 19/05/2015 05:59, O'Driscoll, Tim wrote:
> > a) Save the date. October 8th/9th, immediately after the European
> LinuxCon, in Dublin Ireland.
> > b) Think about topics that you'd like to see covered. We'll solicit for 
> > inputs
> when the formal announcement is made, but it's good for people to begin
> thinking about this now.
> 
> Good idea, thanks for the reminders.
> 
> Some topics on top of my head:
>- community updates & workflow
>- status of PMDs: where are we comming from and where does it go
>-> should it converge with OS' drivers?
>- status of bifurcated drivers & security issues raised on netdev, any
> alternative?
>- status of testing:
>-> dts
>-> smoking tests
> 
> Best regards,
>Vincent
Super thank you

[dpdk-dev] dev@DPDK Hackathon Proposal

[Butler, Siobhan A]

> -Original Message-
> From: Thomas F Herbert [mailto:therbert at redhat.com]
> Sent: Tuesday, May 19, 2015 3:09 PM
> To: Rao, Ravi; O'Driscoll, Tim; Butler, Siobhan A; dev at dpdk.org
> Subject: Re: [dpdk-dev] dev at DPDK Hackathon Proposal
> 
> 
> 
> On 5/19/15 9:43 AM, Rao, Ravi wrote:
> > Hi All,
> > Effort and emphasis has to be made to integrate DPDK into openstack
> components like neutron and nova so that this becomes part of std
> openstack release.
> > Currently some work was done and published as a patch to devstack's Juno
> but there are no clear path to incorporate these patches to the mainline. I
> think this would be a very good topic to cover.
> Yes
> 
> Also related to this, I would hope to participate in any discussion about OVS
> acceration and vhost/guest access acceleration.
> > Regards,
> > Ravi
Thanks Thomas, Ravi - listing both your suggestions. 
Siobhan
> >
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas F Herbert
> > Sent: Tuesday, May 19, 2015 8:37 AM
> > To: O'Driscoll, Tim; Butler, Siobhan A; dev at dpdk.org
> > Subject: Re: [dpdk-dev] dev at DPDK Hackathon Proposal
> >
> > On 5/19/15 8:59 AM, O'Driscoll, Tim wrote:
> >> There wasn't any public response to this but we did discuss it with several
> people separately who all thought it was a good idea. Therefore, we've
> decided to go ahead with it. Siobhan is working on the plan now and should
> be in a position to make a formal announcement in a few weeks.
> >>
> >> In the meantime, I wanted to let people know that this is going ahead so
> that you can:
> >> a) Save the date. October 8th/9th, immediately after the European
> LinuxCon, in Dublin Ireland.
> >> b) Think about topics that you'd like to see covered. We'll solicit for 
> >> inputs
> when the formal announcement is made, but it's good for people to begin
> thinking about this now.
> >>
> > Tim, I for one think it is a good idea. +1 from me.
> >> We'd like this to be quite an interactive event with a lot of discussion
> rather than just presentations. We plan to have many of our key DPDK
> developers there, so it will be a great opportunity to network, discuss the
> technical challenges that you're facing and help to build a stronger DPDK
> community.
> >>
> >
> >>
> >> Tim
> >>
> >>> -Original Message-
> >>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Butler, Siobhan
> >>> A
> >>> Sent: Tuesday, March 31, 2015 7:19 PM
> >>> To: dev at dpdk.org
> >>> Subject: [dpdk-dev] dev at DPDK Hackathon Proposal
> >>>
> >>> Hi all,
> >>>
> >>> As a community we have virtually come together from all over the
> >>> globe, developing now our third successful open source DPDK version
> >>> with DPDK
> >>> r2.0 about to release.
> >>> It is astounding to comprehend the commitment and enthusiasm you
> >>> have all shared to bring DPDK to this point.
> >>> With growing the community of developers in mind, and strengthening
> >>> the networks and virtual collaborations that have come about, I
> >>> propose that we hold the first dev at DPDK Developer Hackathon this
> year.
> >>>
> >>> Many people will be travelling to Dublin, Ireland for LinuxCon and
> >>> CloudOpen October (5th-7th).
> >>> I propose that we hold a hands on 2 day hackathon Thursday October
> >>> 8th and Friday October 9th to coincide with this offering, in Dublin.
> >>>   From a community perspective is a great opportunity to bring
> >>> together the people that make DPDK happen - the developers.
> >>>   From a developer perspective it is a great opportunity to be part
> >>> of the first gathering, meet some new people, learn something new
> >>> and have a lot of fun on the way.
> >>>
> >>> At this point the agenda is open - so if you see merit in this
> >>> proposal please share your interest here so that we can gauge
> >>> attendance and gather ideas of what people would like the format to be.
> >>>
> >>> Thanks,
> >>> Siobhan
> >>> 
> >
> > --
> > Thomas F Herbert
> > Principal Software Engineer
> > Red Hat
> > therbert at redhat.com
> > Office: 919-301-3295
> > Mobile: 804-741-2695
> >
> 
> --
> Thomas F Herbert
> Principal Software Engineer
> Red Hat
> therbert at redhat.com
> Office: 919-301-3295
> Mobile: 804-741-2695

[dpdk-dev] [PATCH] doc: disable doxygen member sorting

[Butler, Siobhan A]

Thanks for making this change John - it helps with readability
Siobhan 

Acked-by Siobhan Butler 

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mcnamara, John
> Sent: Wednesday, April 29, 2015 11:52 AM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: disable doxygen member sorting
> 
> > -Original Message-
> > From: Mcnamara, John
> > Sent: Wednesday, April 29, 2015 11:48 AM
> > To: dev at dpdk.org
> > Cc: Mcnamara, John
> > Subject: [PATCH] doc: disable doxygen member sorting
> >
> > Disabled the doxygen option to sort member data so that functions and
> > struct memebers are listed in order of definition in the brief and
> > main sections.
> 
> 
> 
> See for example:
> 
> http://dpdk.org/doc/api/structlcore__config.html
> 
> The first listed member is "unsigned detected" but the first documented
> member is "void* volatile arg".
> 
> John.
> --
> 
> 
> 

[dpdk-dev] [PATCH] doc: link doxygen docs to source code

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John McNamara
> Sent: Wednesday, April 22, 2015 5:10 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: link doxygen docs to source code
> 
> Enabled Doxygen option to add links to the source code in documented
> entities.
> 
> Signed-off-by: John McNamara 
> ---
>  doc/api/doxy-api.conf | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf index
> da03e9b..c445f80 100644
> --- a/doc/api/doxy-api.conf
> +++ b/doc/api/doxy-api.conf
> @@ -77,3 +77,4 @@ ALPHABETICAL_INDEX  = NO
>  HTML_TIMESTAMP  = NO
>  HTML_DYNAMIC_SECTIONS   = YES
>  SEARCHENGINE= NO
> +SOURCE_BROWSER  = YES
> --
> 1.8.1.4

Thanks John, I think this will help.
Acked-by: Siobhan Butler 

[dpdk-dev] [PATCH v4 5/7] hv: poll mode driver

[Butler, Siobhan A]

Hi Stephen 
Will you have documentation to go along with these changes?
Thanks
Siobhan

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
> Hemminger
> Sent: Tuesday, April 21, 2015 6:33 PM
> To: alexmay at microsoft.com
> Cc: dev at dpdk.org; Stas Egorov; Stephen Hemminger
> Subject: [dpdk-dev] [PATCH v4 5/7] hv: poll mode driver
> 
> From: Stephen Hemminger 
> 
> This is new Poll Mode driver for using hyper-v virtual network
> interface.
> 
> Signed-off-by: Stas Egorov 
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/Makefile  |1 +
>  lib/librte_pmd_hyperv/Makefile|   28 +
>  lib/librte_pmd_hyperv/hyperv.h|  169 
>  lib/librte_pmd_hyperv/hyperv_drv.c| 1653
> +
>  lib/librte_pmd_hyperv/hyperv_drv.h|  558 +++
>  lib/librte_pmd_hyperv/hyperv_ethdev.c |  332 +++
>  lib/librte_pmd_hyperv/hyperv_logs.h   |   69 ++
>  lib/librte_pmd_hyperv/hyperv_rxtx.c   |  403 
>  lib/librte_pmd_hyperv/hyperv_rxtx.h   |   35 +
>  mk/rte.app.mk |4 +
>  10 files changed, 3252 insertions(+)
>  create mode 100644 lib/librte_pmd_hyperv/Makefile
>  create mode 100644 lib/librte_pmd_hyperv/hyperv.h
>  create mode 100644 lib/librte_pmd_hyperv/hyperv_drv.c
>  create mode 100644 lib/librte_pmd_hyperv/hyperv_drv.h
>  create mode 100644 lib/librte_pmd_hyperv/hyperv_ethdev.c
>  create mode 100644 lib/librte_pmd_hyperv/hyperv_logs.h
>  create mode 100644 lib/librte_pmd_hyperv/hyperv_rxtx.c
>  create mode 100644 lib/librte_pmd_hyperv/hyperv_rxtx.h
> 
> diff --git a/lib/Makefile b/lib/Makefile
> index d94355d..6c1daf2 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -47,6 +47,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) +=
> librte_pmd_i40e
>  DIRS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += librte_pmd_fm10k
>  DIRS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += librte_pmd_mlx4
>  DIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += librte_pmd_enic
> +DIRS-$(CONFIG_RTE_LIBRTE_HV_PMD) += librte_pmd_hyperv
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += librte_pmd_bond
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += librte_pmd_ring
>  DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += librte_pmd_pcap
> diff --git a/lib/librte_pmd_hyperv/Makefile
> b/lib/librte_pmd_hyperv/Makefile
> new file mode 100644
> index 000..4ba08c8
> --- /dev/null
> +++ b/lib/librte_pmd_hyperv/Makefile
> @@ -0,0 +1,28 @@
> +#   BSD LICENSE
> +#
> +#   Copyright(c) 2013-2015 Brocade Communications Systems, Inc.
> +#   All rights reserved.
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +#
> +# library name
> +#
> +LIB = librte_pmd_hyperv.a
> +
> +CFLAGS += -O3
> +CFLAGS += $(WERROR_FLAGS)
> +
> +#
> +# all source are stored in SRCS-y
> +#
> +SRCS-$(CONFIG_RTE_LIBRTE_HV_PMD) += hyperv_ethdev.c
> +SRCS-$(CONFIG_RTE_LIBRTE_HV_PMD) += hyperv_rxtx.c
> +SRCS-$(CONFIG_RTE_LIBRTE_HV_PMD) += hyperv_drv.c
> +
> +# this lib depends upon:
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_HV_PMD) += lib/librte_eal lib/librte_ether
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_HV_PMD) += lib/librte_mempool
> lib/librte_mbuf
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_HV_PMD) += lib/librte_malloc
> +
> +include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/lib/librte_pmd_hyperv/hyperv.h
> b/lib/librte_pmd_hyperv/hyperv.h
> new file mode 100644
> index 000..5f66d8a
> --- /dev/null
> +++ b/lib/librte_pmd_hyperv/hyperv.h
> @@ -0,0 +1,169 @@
> +/*-
> + * Copyright (c) 2013-2015 Brocade Communications Systems, Inc.
> + * All rights reserved.
> + */
> +
> +#ifndef _HYPERV_H_
> +#define _HYPERV_H_
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "hyperv_logs.h"
> +
> +#define PAGE_SHIFT   12
> +#define PAGE_SIZE(1 << PAGE_SHIFT)
> +
> +/*
> + * Tunable ethdev params
> + */
> +#define HV_MIN_RX_BUF_SIZE 1024
> +#define HV_MAX_RX_PKT_LEN  4096
> +#define HV_MAX_MAC_ADDRS   1
> +#define HV_MAX_RX_QUEUES   1
> +#define HV_MAX_TX_QUEUES   1
> +#define HV_MAX_PKT_BURST   32
> +#define HV_MAX_LINK_REQ10
> +
> +/*
> + * List of resources mapped from kspace
> + * need to be the same as defined in hv_uio.c
> + */
> +enum {
> + TXRX_RING_MAP,
> + INT_PAGE_MAP,
> + MON_PAGE_MAP,
> + RECV_BUF_MAP
> +};
> +
> +/*
> + * Statistics
> + */
> +struct hv_stats {
> + uint64_t opkts;
> + uint64_t obytes;
> + uint64_t oerrors;
> +
> + uint64_t ipkts;
> + uint64_t ibytes;
> + uint64_t ierrors;
> + uint64_t rx_nombuf;
> +};
> +
> +struct hv_data;
> +struct netvsc_packet;
> +struct rndis_msg;
> +typedef void (*receive_callback_t)(struct hv_data *hv, struct rndis_msg
> *msg,
> + struct netvsc_packet *pkt);
> +
> +/*
> + * Main driver structure
> + */
> +struct hv_data {
> + int vmbus_device;
> + uint8_t monitor_bit;
> + uint8_t monitor_group;
> + uint8_t kernel_initialized;
> + int uio_fd;
> + /* Flag indicates channel state. If closed, RX/TX shouldn't work
> 

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, April 8, 2015 5:16 PM
> To: Wiles, Keith; Butler, Siobhan A
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> 2015-04-08 15:53, Wiles, Keith:
> > One of the biggest problems with any style is helping the developer
> > maintain the style. Using some tool does help and I have used astyle
> > before, not bad code formatter. Here is a few that seem to be reasonable.
> >
> > http://astyle.sourceforge.net/
> >
> > http://uncrustify.sourceforge.net/
> >
> > http://sourceforge.net/projects/gcgreatcode/
> 
> I'm not sure it's a good idea to convert the codebase automatically.
> The coding style must be a reference for new patches and they must be
> automatically checked with a dedicated checkpatch tool.
> By forbidding patches which don't comply, the codebase will be naturally
> converted over time.
> 
> I didn't review this proposal yet.
> My first comment is that it's too long to read :) When a consensus is done, it
> must be added with a patch with custom checkpatch addition.
Thanks Thomas, agreed it is a bit of a novel :)- I will refactor with the 
comments supplied so far and post a fresh version tomorrow.
Siobhan 

[dpdk-dev] [PATCH] doc: fix vhost guide

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Igor Ryzhov
> Sent: Wednesday, April 8, 2015 5:31 PM
> To: dev at dpdk.org
> Cc: Igor Ryzhov
> Subject: [dpdk-dev] [PATCH] doc: fix vhost guide
> 
> Guide says that a configure parameter to choose between vhost cuse and
> vhost user will be introduced in the future, but it?s already added by commit
> 28a1ccca41bf.
Good point Igor- thanks for the spot.
Siobhan
> 
> Signed-off-by: Igor Ryzhov 
> ---
>  doc/guides/sample_app_ug/vhost.rst | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guides/sample_app_ug/vhost.rst
> b/doc/guides/sample_app_ug/vhost.rst
> index 8a7eb3b..df8cd8c 100644
> --- a/doc/guides/sample_app_ug/vhost.rst
> +++ b/doc/guides/sample_app_ug/vhost.rst
> @@ -309,13 +309,12 @@ Compiling the Sample Code
> 
>  CONFIG_RTE_LIBRTE_VHOST=n
> 
> -vhost user is turned on by default in the lib/librte_vhost/Makefile.
> -To enable vhost cuse, uncomment vhost cuse and comment vhost user
> manually. In future, a configure will be created for switch between two
> implementations.
> +vhost user is turned on by default in the configure file
> config/common_linuxapp.
> +To enable vhost cuse, disable vhost user.
> 
>  .. code-block:: console
> 
> -SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_cuse/vhost-net-cdev.c
> vhost_cuse/virtio-net-cdev.c vhost_cuse/eventfd_copy.c
> -#SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_user/vhost-net-user.c
> vhost_user/virtio-net-user.c vhost_user/fd_man.c
> +CONFIG_RTE_LIBRTE_VHOST_USER=y
> 
>   After vhost is enabled and the implementation is selected, build the 
> vhost
> library.
> 
> --
> 1.9.5 (Apple Git-50.3)

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Wednesday, April 8, 2015 7:16 PM
> To: Butler, Siobhan A
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> Thanks for doing this, it is a great start.
> I admit strong bias towards Linux kernel style.
> 
> Could you use one of the standard markup styles so that it could get put in
> documentation?


Sure Stephen - will tidy it all up when we get a consensus :) 
Thanks for the feedback 
Siobhan 
> 
> 
> > License Header
> > --
> 
> I prefer the file just say that it is BSD or GPL and refer to license files 
> in the
> package. That way if something has to change it doesn't need a massive
> license sweep
> 
> 
> >
> > Macros
> >
> > Do not ``#define`` or declare names in the implementation namespace
> except for implementing application interfaces.
> >
> > The names of ``unsafe`` macros (ones that have side effects), and the
> names of macros for manifest constants, are all in uppercase.
> >
> > The expansions of expression-like macros are either a single token or
> > have outer parentheses. If a macro is an inline expansion of a
> > function, the function name is all in lowercase and the macro has the same
> name all in uppercase. Right-justify the backslashes; it makes it easier to
> read. If the macro encapsulates a compound statement, enclose it in a do
> loop, so that it can be used safely in if statements.
> > Any final statement-terminating semicolon should be supplied by the
> macro invocation rather than the macro, to make parsing easier for pretty-
> printers and editors.
> >  #define MACRO(x, y) do {\
> >  variable = (x) + (y);   \
> >  (y) += 2;   \
> >  }while (0)
> ^ bad whitespace
> 
> it is important that all examples in documentation are perfect.
> 
> 
> > C Function Definition, Declaration and Use
> >
> > Prototypes
> >
> > It is recommended, but not required that all functions are prototyped
> somewhere.
> >
> > Any function prototypes for private functions (that is, functions not used
> elsewhere) go at the top of the first source module. Functions
> > local to one source module should be declared static.
> 
> I find prototypes for private functions to be redundant and error prone.
> The do nothing. Better to just put private functions in the correct order.
> 
> 
> You also need to raise the issue that all global names need to be prefaced by
> a unique string.
> I see places in drivers where global names leak out causing possible later
> name collision.
> 
> > Definitions
> > ---
> >
> > The function type should be on a line by itself preceding the function. The
> opening brace of the function body should be on a line by itself.
> >  static char *
> >  function(int a1, int a2, float fl, int a4)
> >  {
> 
> Not a big fan of that style. Prefer it on same line.
> 
> 
> >
> > Indentation is a hard tab, that is, a tab character, not a sequence of 
> > spaces.
> 
> Also no spaces before tabs.
> 
> > NOTE General rule in DPDK, use tabs for indentation, spaces for alignment.
> > If you have to wrap a long statement, put the operator at the end of the
> line, and indent again. For control statements (if, while, etc.),
> > it is recommended that the next line be indented by two tabs, rather than
> one, to prevent confusion as to whether the second line of the
> > control statement forms part of the statement body or not. For non-
> control statements, this issue does not apply, so they can be indented
> > by a single tab. However, a two-tab indent is recommended in this case
> also to keep consistency across all statement types.
> >  while (really_long_variable_name_1 == really_long_variable_name_2 &&
> >  var3 == var4){
> >  x = y + z;  /* control stmt body lines up with second line of */
> >  a = b + c;  /* control statement itself if single indent used */
> >  }
> >
> >  if (really_long_variable_name_1 == really_long_variable_name_2 &&
> >  var3 == var4){  /* two tabs used */
> 
> No. Should line up with really_long_variable_name_1
> 
> >  x = y + z;  /* statement body no longer lines up */
> >  a = b + c;
> >  }
> >
> >  z = a + really + long + statement + that + needs +
> >  two + lines + gets + indented + on + the +
> >

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Wednesday, April 8, 2015 2:11 PM
> To: Butler, Siobhan A
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> On Wed, Apr 08, 2015 at 12:16:10PM +, Butler, Siobhan A wrote:
> >
> >
> > > -Original Message-
> > > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > Sent: Wednesday, April 8, 2015 12:44 PM
> > > To: Butler, Siobhan A
> > > Cc: Thomas Monjalon; dev at dpdk.org
> > > Subject: Re: [dpdk-dev] tools brainstorming
> > >
> > > On Wed, Apr 08, 2015 at 10:43:53AM +, Butler, Siobhan A wrote:
> > > > Hi all,
> > > > To add to the tools brainstorming - I propose we use the following
> > > > Coding
> > > Standards as the basis of guidelines on coding style going forward.
> > > > The style outlined below is in alignment with the current
> > > > convention used
> > > for the majority of the project.
> > > > Any thoughts/suggestions or feedback welcome.
> > > > Thanks
> > > > Siobhan :)
> > > > 
> > > >
> > > >
> > > >
> > > > Coding Style
> > > > ~~
> > > >
> > > > Description
> > > > ---
> > > >
> > > > This document specifies the preferred style for source files in
> > > > the DPDK
> > > source tree.
> > > > It is based on the Linux Kernel coding guidelines and the FreeBSD
> > > > 7.2 Kernel Developer's Manual (see man style(9)), but was heavily
> > > > modified for
> > > the needs of the DPDK. Many of the style rules are implicit in the
> examples.
> > > > Be careful to check the examples before assuming that style is
> > > > silent on an
> > > issue.
> > > >
> > > > General Guidelines
> > > > --
> > > >
> > > > The rules and guidelines given in this document cannot cover every
> > > situation, so the following general guidelines should be used as a 
> > > fallback:
> > > > The code style should be consistent within each individual file,
> > > > and within each file in a given directory or module - in the case
> > > > of creating new
> > > files The primary reason for coding standards is to increase code
> > > readability and comprehensibility, therefore always use whatever
> > > option will make the code easiest to read.
> > > >
> > > > The following more specific recommendations apply to all sections,
> > > > both for
> > > C and assembly code:
> > > > Line length is recommended to be not more than 80 characters,
> > > > including comments. [Tab stop size should be assumed to be at
> > > > least 4-
> > > characters wide] Indentation should be to no more than 3 levels deep.
> > > > NOTE The above are recommendations, and not hard limits. However,
> > > > it is
> > > expected that the recommendations should be followed in all but the
> > > rarest situations.
> > > > C Comment Style
> > > >
> > > > Usual Comments
> > > > --
> > > >
> > > > These comments should be used in normal cases. To document a
> > > > public
> > > API, a doxygen-like format must be used: refer to Doxygen
> Documentation.
> > > >  /*
> > > >   * VERY important single-line comments look like this.
> > > >   */
> > > >
> > > >  /* Most single-line comments look like this. */
> > > >
> > > >  /*
> > > >   * Multi-line comments look like this.  Make them real sentences. Fill
> > > >   * them so they look like real paragraphs.
> > > >   */
> > > >
> > > > License Header
> > > > --
> > > >
> > > > Each file should begin with a special comment tag which will
> > > > contain the
> > > appropriate copyright and license for the file (Generally BSD License).
> > > > After any copyright header, a blank line should be left before any
> > > > other
> > > contents, e.g. include statements in a C file.
> > > >
> > >
> > > This can become very confusing.  There already is a LICENSE.GPL and
> > > LICENSE.LGPL file at the top of the project, allowing others to
>

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Butler, Siobhan A
> Sent: Wednesday, April 8, 2015 1:16 PM
> To: Neil Horman
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> 
> 
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Wednesday, April 8, 2015 12:44 PM
> > To: Butler, Siobhan A
> > Cc: Thomas Monjalon; dev at dpdk.org
> > Subject: Re: [dpdk-dev] tools brainstorming
> >
> > On Wed, Apr 08, 2015 at 10:43:53AM +, Butler, Siobhan A wrote:
> > > Hi all,
> > > To add to the tools brainstorming - I propose we use the following
> > > Coding
> > Standards as the basis of guidelines on coding style going forward.
> > > The style outlined below is in alignment with the current convention
> > > used
> > for the majority of the project.
> > > Any thoughts/suggestions or feedback welcome.
> > > Thanks
> > > Siobhan :)
> > > 
> > >
> > >
> > >
> > > Coding Style
> > > ~~
> > >
> > > Description
> > > ---
> > >
> > > This document specifies the preferred style for source files in the
> > > DPDK
> > source tree.
> > > It is based on the Linux Kernel coding guidelines and the FreeBSD
> > > 7.2 Kernel Developer's Manual (see man style(9)), but was heavily
> > > modified for
> > the needs of the DPDK. Many of the style rules are implicit in the examples.
> > > Be careful to check the examples before assuming that style is
> > > silent on an
> > issue.
> > >
> > > General Guidelines
> > > --
> > >
> > > The rules and guidelines given in this document cannot cover every
> > situation, so the following general guidelines should be used as a fallback:
> > > The code style should be consistent within each individual file, and
> > > within each file in a given directory or module - in the case of
> > > creating new
> > files The primary reason for coding standards is to increase code
> > readability and comprehensibility, therefore always use whatever
> > option will make the code easiest to read.
> > >
> > > The following more specific recommendations apply to all sections,
> > > both for
> > C and assembly code:
> > > Line length is recommended to be not more than 80 characters,
> > > including comments. [Tab stop size should be assumed to be at least
> > > 4-
> > characters wide] Indentation should be to no more than 3 levels deep.
> > > NOTE The above are recommendations, and not hard limits. However, it
> > > is
> > expected that the recommendations should be followed in all but the
> > rarest situations.
> > > C Comment Style
> > >
> > > Usual Comments
> > > --
> > >
> > > These comments should be used in normal cases. To document a public
> > API, a doxygen-like format must be used: refer to Doxygen
> Documentation.
> > >  /*
> > >   * VERY important single-line comments look like this.
> > >   */
> > >
> > >  /* Most single-line comments look like this. */
> > >
> > >  /*
> > >   * Multi-line comments look like this.  Make them real sentences. Fill
> > >   * them so they look like real paragraphs.
> > >   */
> > >
> > > License Header
> > > --
> > >
> > > Each file should begin with a special comment tag which will contain
> > > the
> > appropriate copyright and license for the file (Generally BSD License).
> > > After any copyright header, a blank line should be left before any
> > > other
> > contents, e.g. include statements in a C file.
> > >
Apologies, my mistake the tag format is now out of date - and should be removed 
from the style guide.
Siobhan

> >
> > This can become very confusing.  There already is a LICENSE.GPL and
> > LICENSE.LGPL file at the top of the project, allowing others to insert
> > their own licenses within their files can make it difficult for end
> > user to determine if it is legally safe to use a given project.
> >
> > I'd suggest instead that contributions be disallowed from including
> > license files in their code, relying instead on only a single license
> > at the top of the project (which should likely be BSD or LGPL, since we're
> shipping a library).
> >
> > IANAL, but it

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Wednesday, April 8, 2015 12:44 PM
> To: Butler, Siobhan A
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> On Wed, Apr 08, 2015 at 10:43:53AM +, Butler, Siobhan A wrote:
> > Hi all,
> > To add to the tools brainstorming - I propose we use the following Coding
> Standards as the basis of guidelines on coding style going forward.
> > The style outlined below is in alignment with the current convention used
> for the majority of the project.
> > Any thoughts/suggestions or feedback welcome.
> > Thanks
> > Siobhan :)
> > 
> >
> >
> >
> > Coding Style
> > ~~
> >
> > Description
> > ---
> >
> > This document specifies the preferred style for source files in the DPDK
> source tree.
> > It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2
> > Kernel Developer's Manual (see man style(9)), but was heavily modified for
> the needs of the DPDK. Many of the style rules are implicit in the examples.
> > Be careful to check the examples before assuming that style is silent on an
> issue.
> >
> > General Guidelines
> > --
> >
> > The rules and guidelines given in this document cannot cover every
> situation, so the following general guidelines should be used as a fallback:
> > The code style should be consistent within each individual file, and
> > within each file in a given directory or module - in the case of creating 
> > new
> files The primary reason for coding standards is to increase code readability
> and comprehensibility, therefore always use whatever option will make the
> code easiest to read.
> >
> > The following more specific recommendations apply to all sections, both for
> C and assembly code:
> > Line length is recommended to be not more than 80 characters,
> > including comments. [Tab stop size should be assumed to be at least 4-
> characters wide] Indentation should be to no more than 3 levels deep.
> > NOTE The above are recommendations, and not hard limits. However, it is
> expected that the recommendations should be followed in all but the rarest
> situations.
> > C Comment Style
> >
> > Usual Comments
> > --
> >
> > These comments should be used in normal cases. To document a public
> API, a doxygen-like format must be used: refer to Doxygen Documentation.
> >  /*
> >   * VERY important single-line comments look like this.
> >   */
> >
> >  /* Most single-line comments look like this. */
> >
> >  /*
> >   * Multi-line comments look like this.  Make them real sentences. Fill
> >   * them so they look like real paragraphs.
> >   */
> >
> > License Header
> > --
> >
> > Each file should begin with a special comment tag which will contain the
> appropriate copyright and license for the file (Generally BSD License).
> > After any copyright header, a blank line should be left before any other
> contents, e.g. include statements in a C file.
> >
> 
> This can become very confusing.  There already is a LICENSE.GPL and
> LICENSE.LGPL file at the top of the project, allowing others to insert their
> own licenses within their files can make it difficult for end user to 
> determine
> if it is legally safe to use a given project.
> 
> I'd suggest instead that contributions be disallowed from including license
> files in their code, relying instead on only a single license at the top of 
> the
> project (which should likely be BSD or LGPL, since we're shipping a library).
> 
> IANAL, but it seems to me to be dangerous to do anything else.  For
> example, all the code that is dual licensed in the library (like
> rte_pci_dev_ids.h).  It allows for a BSD or GPL license.  If someone builds
> dpdk as a DSO and distributes it under the former, every application that 
> links
> against that re-distribution may arguably itself become GPL licensed.  While
> I'm personally fine with that, I can see it as being a big deal to some end
> users.  Unifying the license makes the re-distribution license issue more 
> clear
> for everyone.
> 
> Neil


Input appreciated Neil thank you, would it be best to include this in one of 
the community conference calls?
IANAL either ( yet at least :) ) - we can certainly consult with someone who 
has the expertise.
If others are interested in discussing this we can get added to the agenda for 
an upcoming call.

Is more detailed explanation/notice on the licensing structure required?
Thanks,
Siobhan 

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

Hi all,
To add to the tools brainstorming - I propose we use the following Coding 
Standards as the basis of guidelines on coding style going forward.
The style outlined below is in alignment with the current convention used for 
the majority of the project.
Any thoughts/suggestions or feedback welcome.
Thanks
Siobhan :)




Coding Style
~~

Description
---

This document specifies the preferred style for source files in the DPDK source 
tree. 
It is based on the Linux Kernel coding guidelines and the FreeBSD 7.2 Kernel 
Developer's Manual (see man style(9)), 
but was heavily modified for the needs of the DPDK. Many of the style rules are 
implicit in the examples. 
Be careful to check the examples before assuming that style is silent on an 
issue. 

General Guidelines
--

The rules and guidelines given in this document cannot cover every situation, 
so the following general guidelines should be used as a fallback: 
The code style should be consistent within each individual file, and within 
each file in a given directory or module - in the case of creating new files 
The primary reason for coding standards is to increase code readability and 
comprehensibility, therefore always use whatever option will make the code 
easiest to read. 

The following more specific recommendations apply to all sections, both for C 
and assembly code: 
Line length is recommended to be not more than 80 characters, including 
comments. [Tab stop size should be assumed to be at least 4-characters wide] 
Indentation should be to no more than 3 levels deep. 
NOTE The above are recommendations, and not hard limits. However, it is 
expected that the recommendations should be followed in all but the rarest 
situations. 
C Comment Style

Usual Comments
--

These comments should be used in normal cases. To document a public API, a 
doxygen-like format must be used: refer to Doxygen Documentation. 
 /*
  * VERY important single-line comments look like this.
  */

 /* Most single-line comments look like this. */

 /*
  * Multi-line comments look like this.  Make them real sentences. Fill
  * them so they look like real paragraphs.
  */

License Header
--

Each file should begin with a special comment tag which will contain the 
appropriate copyright and license for the file (Generally BSD License). 
After any copyright header, a blank line should be left before any other 
contents, e.g. include statements in a C file. 

C Preprocessor Directives
-

Header Includes

In DPDK sources, the include files should be ordered as following: 
 libc includes (system includes first) 
 DPDK EAL includes 
 DPDK misc libraries includes 
 application-specific includes 

Example: 
 #include 
 #include 

 #include 

 #include 
 #include 

 #include "application.h"


Global pathnames are defined in . Pathnames local to the program go in 
"pathnames.h" in the local directory. 
 #include 


Leave another blank line before the user include files. 
 #include "pathnames.h" /* Local includes in double quotes. */

NOTE Please avoid, as much as possible, including headers from other headers 
file. Doing so should be properly explained and justified. 
Headers should be protected against multiple inclusion with the usual: 
 #ifndef _FILE_H_
 #define _FILE_H_

 /* Code */

 #endif /* _FILE_H_ */


Macros

Do not ``#define`` or declare names in the implementation namespace except for 
implementing application interfaces. 

The names of ``unsafe`` macros (ones that have side effects), and the names of 
macros for manifest constants, are all in uppercase. 

The expansions of expression-like macros are either a single token or have 
outer parentheses. If a macro is an inline expansion of a function, 
the function name is all in lowercase and the macro has the same name all in 
uppercase. Right-justify the backslashes; 
it makes it easier to read. If the macro encapsulates a compound statement, 
enclose it in a do loop, so that it can be used safely in if statements. 
Any final statement-terminating semicolon should be supplied by the macro 
invocation rather than the macro, to make parsing easier for pretty-printers 
and editors. 
 #define MACRO(x, y) do {\
 variable = (x) + (y);   \
 (y) += 2;   \
 }while (0)

NOTE Wherever possible, enums and typedefs should be preferred to macros, since 
they provide additional degrees 
of type-safety and can allow compilers to emit extra warnings about unsafe 
code. 

Conditional Compilation
---

When code is conditionally compiled using #ifdef or #if, a comment may be added 
following the matching #endif or #else to 
permit the reader to easily discern where conditionally compiled code regions 
end. This comment should be used only for 
(subjectively) long regions, regions greater than 20 lines, o

[dpdk-dev] [PATCH] doc: add notes for i40e firmware version

[Butler, Siobhan A]

> From: Zhang, Helin
> Sent: Friday, April 3, 2015 9:07 AM
> To: dev at dpdk.org
> Cc: Butler, Siobhan A; Wu, Jingjing; Liu, Jijiang; Zhang, Helin
> Subject: [PATCH] doc: add notes for i40e firmware version
> 
> Added notes for i40e firmware version. As base driver to suppor the latest
> version of firmware (FVL3E) hasn't been integrated, currently the validated
> version of firmware is 4.2.6.
> 
> Signed-off-by: Helin Zhang 
> ---
>  doc/guides/linux_gsg/enable_func.rst | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/doc/guides/linux_gsg/enable_func.rst
> b/doc/guides/linux_gsg/enable_func.rst
> index 9db3b5a..56084b2 100644
> --- a/doc/guides/linux_gsg/enable_func.rst
> +++ b/doc/guides/linux_gsg/enable_func.rst
> @@ -176,6 +176,7 @@ High Performance of Small Packets on 40G NIC  As
> there might be firmware fixes for performance enhancement in latest
> version  of firmware image, the firmware update might be needed for
> getting high performance.
>  Check with the local Intel's Network Division application engineers for
> firmware updates.
> +The base driver to support firmware version of FVL3E will be integrated in
> the next DPDK release, so currently the validated firmware version is 4.2.6.
> 
>  Enabling Extended Tag and Setting Max Read Request Size
> ~~~
> --
> 1.8.1.4
Applies ok, builds ok,
Acked-by Siobhan Butler 

[dpdk-dev] [PATCH 2/5] mk: reduce PDF build commands

[Butler, Siobhan A]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, April 2, 2015 8:58 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 2/5] mk: reduce PDF build commands
> 
> In case of documents without image, an empty rm command can be seen if
> V=1.
> Remove it to avoid disturbing debugging.
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  mk/rte.sdkdoc.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mk/rte.sdkdoc.mk b/mk/rte.sdkdoc.mk index f91e079..9952f25
> 100644
> --- a/mk/rte.sdkdoc.mk
> +++ b/mk/rte.sdkdoc.mk
> @@ -99,7 +99,7 @@ guides-pdf-%:
>   $(Q)$(RTE_SPHINX_BUILD) -b latex $(RTE_SPHINX_VERBOSE) \
>   -c $(RTE_SDK)/doc/guides $(RTE_SDK)/doc/guides/$* \
>   $(RTE_OUTPUT)/doc/pdf/guides/$*
> - $(Q)rm -f $^
> + $(if $^,$(Q)rm -f $^)
>   @echo 'pdflatex processing $@...'
>   $(Q)$(MAKE) all-pdf -sC $(RTE_OUTPUT)/doc/pdf/guides/$* \
>   LATEXOPTS=$(RTE_PDFLATEX_VERBOSE)
> --
> 2.2.2
Acked-by Siobhan Butler 

[dpdk-dev] [PATCH] doc: update version number in release notes description

[Butler, Siobhan A]

> -Original Message-
> From: Butler, Siobhan A
> Sent: Thursday, April 2, 2015 9:42 PM
> To: dev at dpdk.org
> Cc: Butler, Siobhan A
> Subject: [PATCH] doc: update version number in release notes description
> 
> Signed-off-by: Siobhan Butler 
> ---
>  doc/guides/rel_notes/rel_description.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/guides/rel_notes/rel_description.rst
> b/doc/guides/rel_notes/rel_description.rst
> index c8ff483..2fb5379 100644
> --- a/doc/guides/rel_notes/rel_description.rst
> +++ b/doc/guides/rel_notes/rel_description.rst
> @@ -32,7 +32,7 @@ Description of Release  ==
> 
>  These release notes cover the new features, -fixed bugs and known issues
> for Data Plane Development Kit (DPDK) release version 1.7.0.
> +fixed bugs and known issues for Data Plane Development Kit (DPDK)
> release version 2.0.
> 
>  For instructions on compiling and running the release, see the *DPDK
> Getting Started Guide*.
> 
> --
> 1.8.3.1
Ignore this patch - superseded by patch to change all the version numbers.
Thanks
S

[dpdk-dev] [PATCH] ixgbe: do not include CRC in Tx byte count

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
> Hemminger
> Sent: Tuesday, March 24, 2015 3:55 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org; Stephen Hemminger
> Subject: Re: [dpdk-dev] [PATCH] ixgbe: do not include CRC in Tx byte count
> 
> On Mon, 23 Mar 2015 16:45:44 +
> "Ananyev, Konstantin"  wrote:
> 
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of
> > > stephen at networkplumber.org
> > > Sent: Friday, January 23, 2015 6:24 AM
> > > To: dev at dpdk.org
> > > Cc: Stephen Hemminger
> > > Subject: [dpdk-dev] [PATCH] ixgbe: do not include CRC in Tx byte
> > > count
> > >
> > > From: Stephen Hemminger 
> > >
> > > The ixgbe driver was including CRC in the transmit packet byte
> > > count, but not for packets received.
> > > This was notice when forwarding and
> > > the number of bytes received was greater than the number of bytes
> > > transmitted for the same number of packets. Make the driver behave
> > > like other virtual devices and not include CRC in byte count. Use
> > > the same queue counters already computed and used for Rx.
> >
> > About RX side stats - as I remember it depends to what value hw_stip_crc
> is set at configure().
> > If hw_stip_crc==1, then, yes CRC bytes are not included into  QBRC value.
> > I If hw_stip_crc==0, then CRC bytes are included into QBRC.
> 
> That is an additional bug!
>   * CRC should never be included in the byte count.
> This is not how Linux or other drivers report byte count.
> 
>   * the byte count must be symmetrical Rx == Tx
> 
> The Brocade router always set strip_crc to 1. So did not see the additional
> bug of CRC being included in byte count.
> 
> 
Great to see some discussion here all but can we hold on to the patch until 
after the 2.0 package is made so there is enough time to review and test it 
properly?
Thanks 
Siobhan

[dpdk-dev] [PATCH v3] ixgbe: fix data access on big endian cpu

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of
> xuelin.shi at freescale.com
> Sent: Tuesday, March 31, 2015 8:26 AM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org; Xuelin Shi
> Subject: [dpdk-dev] [PATCH v3] ixgbe: fix data access on big endian cpu
> 
> From: Xuelin Shi 
> 
> enforce rules of the cpu and ixgbe exchange data.
> 1. cpu use data owned by ixgbe must use rte_le_to_cpu_xx(...) 2. cpu fill
> data to ixgbe must use rte_cpu_to_le_xx(...) 3. checking pci status with
> converted constant.
> 
> Signed-off-by: Xuelin Shi 
> ---
> change for v3:
>check pci status with converted constant to avoid performance penalty.
>remove tmp variable.
> 
>  lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 89 ---
> 
>  1 file changed, 56 insertions(+), 33 deletions(-)
> 
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> index 9da2c7e..6e508ec 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> @@ -129,7 +129,7 @@ ixgbe_tx_free_bufs(struct ixgbe_tx_queue *txq)
> 
>   /* check DD bit on threshold descriptor */
>   status = txq->tx_ring[txq->tx_next_dd].wb.status;
> - if (! (status & IXGBE_ADVTXD_STAT_DD))
> + if (!(status & rte_cpu_to_le_32(IXGBE_ADVTXD_STAT_DD)))
>   return 0;
> 
>   /*
> @@ -174,11 +174,14 @@ tx4(volatile union ixgbe_adv_tx_desc *txdp, struct
> rte_mbuf **pkts)
>   pkt_len = (*pkts)->data_len;
> 
>   /* write data to descriptor */
> - txdp->read.buffer_addr = buf_dma_addr;
> + txdp->read.buffer_addr =
> rte_cpu_to_le_64(buf_dma_addr);
> +
>   txdp->read.cmd_type_len =
> - ((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
> + rte_cpu_to_le_32((uint32_t)DCMD_DTYP_FLAGS |
> pkt_len);
> +
>   txdp->read.olinfo_status =
> - (pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
> + rte_cpu_to_le_32(pkt_len <<
> IXGBE_ADVTXD_PAYLEN_SHIFT);
> +
>   rte_prefetch0(&(*pkts)->pool);
>   }
>  }
> @@ -194,11 +197,14 @@ tx1(volatile union ixgbe_adv_tx_desc *txdp, struct
> rte_mbuf **pkts)
>   pkt_len = (*pkts)->data_len;
> 
>   /* write data to descriptor */
> - txdp->read.buffer_addr = buf_dma_addr;
> + txdp->read.buffer_addr = rte_cpu_to_le_64(buf_dma_addr);
> +
>   txdp->read.cmd_type_len =
> - ((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
> + rte_cpu_to_le_32((uint32_t)DCMD_DTYP_FLAGS |
> pkt_len);
> +
>   txdp->read.olinfo_status =
> - (pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
> + rte_cpu_to_le_32(pkt_len <<
> IXGBE_ADVTXD_PAYLEN_SHIFT);
> +
>   rte_prefetch0(&(*pkts)->pool);
>  }
> 
> @@ -285,7 +291,7 @@ tx_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts,
>* a divisor of the ring size
>*/
>   tx_r[txq->tx_next_rs].read.cmd_type_len |=
> - rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
> +
>   rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
>   txq->tx_next_rs = (uint16_t)(txq->tx_rs_thresh - 1);
> 
>   txq->tx_tail = 0;
> @@ -304,7 +310,7 @@ tx_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts,
>*/
>   if (txq->tx_tail > txq->tx_next_rs) {
>   tx_r[txq->tx_next_rs].read.cmd_type_len |=
> - rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
> +
>   rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
>   txq->tx_next_rs = (uint16_t)(txq->tx_next_rs +
>   txq->tx_rs_thresh);
>   if (txq->tx_next_rs >= txq->nb_tx_desc) @@ -505,6 +511,7
> @@ ixgbe_xmit_cleanup(struct ixgbe_tx_queue *txq)
>   uint16_t nb_tx_desc = txq->nb_tx_desc;
>   uint16_t desc_to_clean_to;
>   uint16_t nb_tx_to_clean;
> + uint32_t stat;
> 
>   /* Determine the last descriptor needing to be cleaned */
>   desc_to_clean_to = (uint16_t)(last_desc_cleaned + txq-
> >tx_rs_thresh); @@ -513,7 +520,9 @@ ixgbe_xmit_cleanup(struct
> ixgbe_tx_queue *txq)
> 
>   /* Check to make sure the last descriptor to clean is done */
>   desc_to_clean_to = sw_ring[desc_to_clean_to].last_id;
> - if (! (txr[desc_to_clean_to].wb.status & IXGBE_TXD_STAT_DD))
> +
> + stat = txr[desc_to_clean_to].wb.status;
> + if (!(stat & rte_cpu_to_le_32(IXGBE_TXD_STAT_DD)))
>   {
>   PMD_TX_FREE_LOG(DEBUG,
>   "TX descriptor %4u is not done"
> @@ -801,12 +810,14 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts,
>*/
>   slen = m_seg->data_len;
>   buf_dma_addr =
> RTE_MBUF_DATA_DMA_ADDR(m_seg);
> +
>   txd->read.buffer_addr =
> - rte_cpu_to_le_64(buf_dma_addr);
> 

[dpdk-dev] [PATCH] mbuf: clean old refcnt option

[Butler, Siobhan A]

Huawei/Changchun can you please ack this patch or if you are not happy with it 
ask for it to be deffered but it is blocking.
Thank you 
S

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, April 1, 2015 8:58 PM
> To: Xie, Huawei; Ouyang, Changchun
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] mbuf: clean old refcnt option
> 
> 2015-03-31 21:26, Olivier MATZ:
> > Hi Thomas,
> >
> > On 03/31/2015 07:58 PM, Thomas Monjalon wrote:
> > > CONFIG_RTE_MBUF_SCATTER_GATHER was renamed into
> > > CONFIG_RTE_MBUF_REFCNT by commit 62814bc2e923 and removed by
> commit 4769bc5a27cc.
> > > Some traces remain because of delayed patches.
> > >
> > > It can also be removed from doxygen config.
> > > It is now poisoned in rte_mbuf.h to warn any misuse.
> > >
> > > Fixes: d0dff9ba445e ("doc: sample application user guide")
> > > Fixes: fc1f2750a3ec ("doc: programmers guide")
> > > Fixes: 4769bc5a27cc ("mbuf: remove build option to disable refcnt")
> > >
> > > Signed-off-by: Thomas Monjalon 
> [...]
> > > --- a/doc/guides/sample_app_ug/vhost.rst
> > > +++ b/doc/guides/sample_app_ug/vhost.rst
> > > @@ -338,28 +338,6 @@ Compiling the Sample Code
> > >
> > >  .. code-block:: console
> > >
> > > -make
> > > -
> > > -.. note::
> > > -
> > > -Note For zero copy, need firstly disable
> CONFIG_RTE_MBUF_SCATTER_GATHER,
> > > -CONFIG_RTE_LIBRTE_IP_FRAG and
> CONFIG_RTE_LIBRTE_DISTRIBUTOR
> > > -in the config file and then re-configure and compile the core 
> > > lib, and
> then build the application:
> > > -
> > > -.. code-block:: console
> > > -
> > > -vi ${RTE_SDK}/config/common_linuxapp
> > > -
> > > -change it as follows:
> > > -
> > > -::
> > > -
> > > -CONFIG_RTE_MBUF_SCATTER_GATHER=n
> > > -CONFIG_RTE_LIBRTE_IP_FRAG=n
> > > -CONFIG_RTE_LIBRTE_DISTRIBUTOR=n
> > > -
> > > -.. code-block:: console
> > > -
> > >  cd ${RTE_SDK}
> > >  make config ${RTE_TARGET}
> > >  make install ${RTE_TARGET}
> 
> Note that make config is useless and T= is missing.
> 
> > I have one doubt about the vhost part, as the previous doc was telling
> > to disable refcnt option and now the behavior is equivalent to having
> > the option always enabled. Also you are removing parts of doc that
> > talk about CONFIG_RTE_LIBRTE_DISTRIBUTOR and
> CONFIG_RTE_LIBRTE_IP_FRAG.
> >
> > It would be safer to also have an acknowledgment from a vhost expert.
> 
> Huawei, Changchun, any opinion please?

[dpdk-dev] [PATCH] doc: add note for txqflags in testpmd UG

[Butler, Siobhan A]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, April 1, 2015 1:10 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: add note for txqflags in testpmd UG
> 
> Since txqflags is now set from the default rx/tx configuration, depending on
> the PMD, it might not be 0.
> Therefore, user has to overwrite it with --txqflags 0.
> 
> Signed-off-by: Pablo de Lara 
> ---
>  doc/guides/testpmd_app_ug/run_app.rst |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/guides/testpmd_app_ug/run_app.rst
> b/doc/guides/testpmd_app_ug/run_app.rst
> index 6cbbf40..b29c176 100644
> --- a/doc/guides/testpmd_app_ug/run_app.rst
> +++ b/doc/guides/testpmd_app_ug/run_app.rst
> @@ -405,6 +405,12 @@ They must be separated from the EAL options,
> shown in the previous section, with
>  Set the hexadecimal bitmask of TX queue flags, where 0 <= N <=
> 0x7FFF.
>  The default value is 0.
> 
> +Note::
> +
> +When using hardware offload functions such as vlan, checksum...,
> +add txqflags=0, since depending on the PMD,
> +txqflags might be set to a non-zero value.
> +
>  *   --rx-queue-stats-
> mapping=(port,queue,mapping)[,(port,queue,mapping)]
> 
>  Set the RX queues statistics counters mapping 0 <= mapping <= 15.
> --
> 1.7.4.1

Thanks Pablo that wording is better
Acked-by Siobhan Butler 

[dpdk-dev] dev@DPDK Hackathon Proposal

[Butler, Siobhan A]

Hi all,

As a community we have virtually come together from all over the globe, 
developing now our third successful open source DPDK version with DPDK r2.0 
about to release.
It is astounding to comprehend the commitment and enthusiasm you have all 
shared to bring DPDK to this point.
With growing the community of developers in mind, and strengthening the 
networks and virtual collaborations that have come about,
I propose that we hold the first dev at DPDK Developer Hackathon this year.

Many people will be travelling to Dublin, Ireland for LinuxCon and CloudOpen 
October (5th-7th).
I propose that we hold a hands on 2 day hackathon Thursday October 8th and 
Friday October 9th to coincide with this offering, in Dublin.
>From a community perspective is a great opportunity to bring together the 
>people that make DPDK happen - the developers.
>From a developer perspective it is a great opportunity to be part of the first 
>gathering, meet some new people, learn something new
and have a lot of fun on the way.

At this point the agenda is open - so if you see merit in this proposal please 
share your interest here so that we can gauge attendance
and gather ideas of what people would like the format to be.

Thanks,
Siobhan

[dpdk-dev] [PATCH] doc: added missing new EAL options in testpmd UG

[Butler, Siobhan A]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Friday, March 27, 2015 4:50 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: added missing new EAL options in testpmd
> UG
> 
> Added information on testpmd user guide
> for -l, --lcores and --master-lcore options
> 
> Signed-off-by: Pablo de Lara 
> ---
>  doc/guides/testpmd_app_ug/run_app.rst |   23
> +++
>  1 files changed, 23 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/guides/testpmd_app_ug/run_app.rst
> b/doc/guides/testpmd_app_ug/run_app.rst
> index 3898e67..21e6c27 100644
> --- a/doc/guides/testpmd_app_ug/run_app.rst
> +++ b/doc/guides/testpmd_app_ug/run_app.rst
> @@ -42,6 +42,29 @@ See the DPDK Getting Started Guide for more
> information on these options.
> 
>  Set the hexadecimal bitmask of the cores to run on.
> 
> +*   -l CORELIST
> +
> +List of cores to run on
> +
> +The argument format is [-c2][,c3[-c4],...]
> +where c1, c2, etc are core indexes between 0 and 128
> +
> +*   --lcores COREMAP
> +
> +Map lcore set to physical cpu set
> +
> +The argument format is
> +'[<,lcores[@cpus]>...]'
> +lcores and cpus list are grouped by '(' and ')'
> +Within the group, '-' is used for range separator,
> +',' is used for single number separator.
> +'( )' can be omitted for single element group,
> +'@' can be omitted if cpus and lcores have the same value
> +
> +*   --master-lcore ID
> +
> +Core ID that is used as master
> +
>  *   -n NUM
> 
>  Set the number of memory channels to use.
> --
> 1.7.4.1

Acked-by Siobhan Butler 

[dpdk-dev] [PATCH v4] doc: Update doc for vhost sample

[Butler, Siobhan A]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John McNamara
> Sent: Friday, March 27, 2015 1:20 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4] doc: Update doc for vhost sample
> 
> From: Ouyang Changchun 
> 
> Added some documentation on common issues for the vhost sample app
> and how to resolve them.
> 
> Signed-off-by: Changchun Ouyang 
> Signed-off-by: John McNamara 
> ---
>  doc/guides/sample_app_ug/vhost.rst | 58
> --
>  1 file changed, 50 insertions(+), 8 deletions(-)
> 
> diff --git a/doc/guides/sample_app_ug/vhost.rst
> b/doc/guides/sample_app_ug/vhost.rst
> index 4a6d434..7e333cf 100644
> --- a/doc/guides/sample_app_ug/vhost.rst
> +++ b/doc/guides/sample_app_ug/vhost.rst
> @@ -1,3 +1,4 @@
> +
>  ..  BSD LICENSE
>  Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>  All rights reserved.
> @@ -640,19 +641,60 @@ To call the QEMU wrapper automatically from
> libvirt, the following configuration  Common Issues  ~
> 
> -**QEMU failing to allocate memory on hugetlbfs.**
> +*   QEMU failing to allocate memory on hugetlbfs, with an error like the
> following::
> 
> -file_ram_alloc: can't mmap RAM pages: Cannot allocate memory
> +   file_ram_alloc: can't mmap RAM pages: Cannot allocate memory
> 
> -When running QEMU the above error implies that it has failed to allocate
> memory for the Virtual Machine on the hugetlbfs.
> -This is typically due to insufficient hugepages being free to support the
> allocation request.
> -The number of free hugepages can be checked as follows:
> +When running QEMU the above error indicates that it has failed to
> allocate memory for the Virtual Machine on
> +the hugetlbfs. This is typically due to insufficient hugepages being 
> free to
> support the allocation request.
> +The number of free hugepages can be checked as follows:
> 
> -.. code-block:: console
> +.. code-block:: console
> +
> +cat /sys/kernel/mm/hugepages/hugepages-/nr_hugepages
> +
> +The command above indicates how many hugepages are free to support
> QEMU's allocation request.
> +
> +*   User space VHOST when the guest has 2MB sized huge pages:
> +
> +The guest may have 2MB or 1GB sized huge pages. The user space VHOST
> should work properly in both cases.
> +
> +*   User space VHOST will not work with QEMU without the ``-mem-
> prealloc`` option:
> +
> +The current implementation works properly only when the guest memory
> is pre-allocated, so it is required to
> +use a QEMU version (e.g. 1.6) which supports ``-mem-prealloc``. The ``-
> mem-prealloc`` option must be
> +specified explicitly in the QEMU command line.
> +
> +*   User space VHOST will not work with a QEMU version without shared
> memory mapping:
> +
> +As shared memory mapping is mandatory for user space VHOST to work
> properly with the guest, user space VHOST
> +needs access to the shared memory from the guest to receive and
> transmit packets. It is important to make sure
> +the QEMU version supports shared memory mapping.
> +
> +*   Issues with ``virsh destroy`` not destroying the VM:
> +
> +Using libvirt ``virsh create`` the ``qemu-wrap.py`` spawns a new process 
> to
> run ``qemu-kvm``. This impacts the behavior
> +of ``virsh destroy`` which kills the process running ``qemu-wrap.py``
> without actually destroying the VM (it leaves
> +the ``qemu-kvm`` process running):
> +
> +This following patch should fix this issue:
> +http://dpdk.org/ml/archives/dev/2014-June/003607.html
> +
> +*   In an Ubuntu environment, QEMU fails to start a new guest normally
> with user space VHOST due to not being able
> +to allocate huge pages for the new guest:
> +
> +The solution for this issue is to add ``-boot c`` into the QEMU command
> line to make sure the huge pages are
> +allocated properly and then the guest should start normally.
> +
> +Use ``cat /proc/meminfo`` to check if there is any changes in the value 
> of
> ``HugePages_Total`` and ``HugePages_Free``
> +after the guest startup.
> +
> +*   Log message: ``eventfd_link: module verification failed: signature and/or
> required key missing - tainting kernel``:
> 
> -user at target:cat /sys/kernel/mm/hugepages/hugepages- /
> nr_hugepages
> +This log message may be ignored. The message occurs due to the kernel
> module ``eventfd_link``, which is not a standard
> +Linux module but which is necessary for the user space VHOST current
> implementation (CUSE-based) to communicate with
> +the guest.
> 
> -The command above indicates how many hugepages are free to support
> QEMU's allocation request.
> 
>  Running DPDK in the Virtual Machine
>  ---
> --
> V4: Fixed typos and syntax.
> V3: Fixed indentation issue that prevented PDFs from building.
> 
> 
> 1.8.1.4

Acked-by Siobhan Butler 

[dpdk-dev] documentation for 2.0

[Butler, Siobhan A]

Hi all,

Does anyone have remaining documentation changes for release 2.0 - if so can 
you please post immediately?

Many Thanks,
Siobhan

[dpdk-dev] [PATCH] vhost library doc update

[Butler, Siobhan A]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
> Sent: Wednesday, March 11, 2015 4:22 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] vhost library doc update
> 
> add vhost user documentation
> 
> Signed-off-by: Huawei Xie 
> ---
>  doc/guides/prog_guide/vhost_lib.rst | 52
> ++---
>  1 file changed, 42 insertions(+), 10 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/vhost_lib.rst
> b/doc/guides/prog_guide/vhost_lib.rst
> index 0b6eda7..ab35b74 100644
> --- a/doc/guides/prog_guide/vhost_lib.rst
> +++ b/doc/guides/prog_guide/vhost_lib.rst
> @@ -31,25 +31,28 @@
>  Vhost Library
>  =
> 
> -The vhost cuse (cuse: user space character device driver) library implements
> a -vhost cuse driver. It also creates, manages and destroys vhost devices for 
> -
> corresponding virtio devices in the guest. Vhost supported vSwitch could
> register -callbacks to this library, which will be called when a vhost device 
> is
> activated -or deactivated by guest virtual machine.
> +The vhost library implements a user space vhost driver. It supports
> +both vhost-cuse
> +(cuse: user space character device) and vhost-user(user space socket
> server).
> +It also creates, manages and destroys vhost devices for corresponding
> +virtio devices in the guest. Vhost supported vSwitch could register
> +callbacks to this library, which will be called when a vhost device is
> +activated or deactivated by guest virtual machine.
> 
>  Vhost API Overview
>  --
> 
>  *   Vhost driver registration
> 
> -  rte_vhost_driver_register registers the vhost cuse driver into the
> system.
> -  Character device file will be created in the /dev directory.
> +  rte_vhost_driver_register registers the vhost driver into the system.
> +  For vhost-cuse, character device file will be created under the /dev
> directory.
>Character device name is specified as the parameter.
> +  For vhost-user, a unix domain socket server will be created with the
> parameter as
> +  the local socket path.
> 
>  *   Vhost session start
> 
>rte_vhost_driver_session_start starts the vhost session loop.
> -  Vhost cuse session is an infinite blocking loop.
> +  Vhost session is an infinite blocking loop.
>Put the session in a dedicate DPDK thread.
> 
>  *   Callback register
> @@ -73,6 +76,8 @@ Vhost API Overview
>  Vhost Implementation
>  
> 
> +Vhost cuse implementation
> +~
>  When vSwitch registers the vhost driver, it will register a cuse device 
> driver
> into the system and creates a character device file. This cuse driver will
> receive vhost open/release/IOCTL message from QEMU simulator.
> @@ -89,13 +94,40 @@ which means vhost could access the shared virtio ring
> and the guest physical  address specified in the entry of the ring.
> 
>  The guest virtual machine tells the vhost whether the virtio device is ready 
> -
> for processing or is de-activated through VHOST_SET_BACKEND message.
> +for processing or is de-activated through VHOST_NET_SET_BACKEND
> message.
>  The registered callback from vSwitch will be called.
> 
>  When the release call is released, vhost will destroy the device.
> 
> +Vhost user implementation
> +~
> +When vSwitch registers a vhost driver, it will create a unix domain
> +socket server into the system. This server will listen for a connection
> +and process the vhost message from QEMU simulator.
> +
> +When there is a new socket connection, it means a new virtio device has
> +been created in the guest virtual machine, and the vhost driver will create a
> vhost device for this virtio device.
> +
> +For messages with a file descriptor, the file descriptor could be
> +directly used in the vhost process as it is already installed by unix domain
> socket.
> + * VHOST_SET_MEM_TABLE
> + * VHOST_SET_VRING_KICK
> + * VHOST_SET_VRING_CALL
> + * VHOST_SET_LOG_FD
> + * VHOST_SET_VRING_ERR
> +
> +For VHOST_SET_MEM_TABLE message, QEMU will send us information for
> each
> +memory region and its file descriptor in the ancillary data of the message.
> The fd is used to map that region.
> +
> +There is no VHOST_NET_SET_BACKEND message as in vhost cuse to signal
> us
> +whether virtio device is ready or should be stopped.
> +VHOST_SET_VRING_KICK is used as the signal to put the vhost device onto
> data plane.
> +VHOST_GET_VRING_BASE is used as the signal to remove vhost device
> from data plane.
> +
> +When the socket connection is closed, vhost will destroy the device.
> +
>  Vhost supported vSwitch reference
>  -
> 
> -For how to support vhost in vSwitch, please refer to vhost example in the
> +For more vhost details and how to support vhost in vSwitch, please
> +refer to vhost example in the
>  DPDK Sample Applications Guide.
> --
> 1.8.1.4

Acked-by Siobhan Butler 

[dpdk-dev] [PATCH] doc: add note on needing igb_uio module for VF devs

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, Bernard
> Sent: Wednesday, March 25, 2015 10:43 AM
> To: Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: add note on needing igb_uio module
> for VF devs
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Monday, March 23, 2015 4:20 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH] doc: add note on needing igb_uio module
> > for VF devs
> >
> > Since the uio_pci_generic module requires that the device to which it
> > is being bound supports legacy interrupts, there can be problems using
> > it with VF devices. Add a note to the GSG doc to document this fact, and
> provide information on loading igb_uio as a replacement.
> >
> > Signed-off-by: Bruce Richardson 
> 
> Acked-by: Bernard Iremonger 

Acked-by: Siobhan Butler 

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, March 23, 2015 4:19 PM
> To: Butler, Siobhan A
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] tools brainstorming
> 
> 2015-03-20 15:07, Butler, Siobhan A:
> > I propose we also add a bug tracking tool (e.g. Bugzilla or other).
> 
> Don't you think adding a bug tracker would artificially split discussions
> between mailing list threads and bug tracker entries?
> I think patchwork is great because it summarizes patches pending on the
> mailing list without breaking the discussion flow.

I see your point, I just think it might be a useful mechanism for people 
getting started as contributors - to pick up a bug and fix it, as well
a better way of tracking the known and resolved issues which are a nightmare to 
maintain in the documentation.

> Maybe that a tool which collect bug discussions - as patchwork do for the
> patches - would be ideal?

Sounds great if one exists.

> 
> > And also a standalone page/document/archive of FAQ's.
> 
> Which kind of questions do you want to answer?
> You're adding some technical questions in the release notes, which is great.
> Are you thinking to anything else?
> 

To have these questions and answers more visible really was my main objective.

> Thanks

[dpdk-dev] [PATCH] vhost library doc update

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
> Sent: Wednesday, March 11, 2015 4:22 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] vhost library doc update
> 
> add vhost user documentation
> 
> Signed-off-by: Huawei Xie 
> ---
>  doc/guides/prog_guide/vhost_lib.rst | 52
> ++---
>  1 file changed, 42 insertions(+), 10 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/vhost_lib.rst
> b/doc/guides/prog_guide/vhost_lib.rst
> index 0b6eda7..ab35b74 100644
> --- a/doc/guides/prog_guide/vhost_lib.rst
> +++ b/doc/guides/prog_guide/vhost_lib.rst
> @@ -31,25 +31,28 @@
>  Vhost Library
>  =
> 
> -The vhost cuse (cuse: user space character device driver) library implements
> a -vhost cuse driver. It also creates, manages and destroys vhost devices for 
> -
> corresponding virtio devices in the guest. Vhost supported vSwitch could
> register -callbacks to this library, which will be called when a vhost device 
> is
> activated -or deactivated by guest virtual machine.
> +The vhost library implements a user space vhost driver. It supports
> +both vhost-cuse
> +(cuse: user space character device) and vhost-user(user space socket
> server).
> +It also creates, manages and destroys vhost devices for corresponding
> +virtio devices in the guest. Vhost supported vSwitch could register
> +callbacks to this library, which will be called when a vhost device is
> +activated or deactivated by guest virtual machine.
> 
>  Vhost API Overview
>  --
> 
>  *   Vhost driver registration
> 
> -  rte_vhost_driver_register registers the vhost cuse driver into the
> system.
> -  Character device file will be created in the /dev directory.
> +  rte_vhost_driver_register registers the vhost driver into the system.
> +  For vhost-cuse, character device file will be created under the /dev
> directory.
>Character device name is specified as the parameter.
> +  For vhost-user, a unix domain socket server will be created with the
> parameter as
> +  the local socket path.
> 
>  *   Vhost session start
> 
>rte_vhost_driver_session_start starts the vhost session loop.
> -  Vhost cuse session is an infinite blocking loop.
> +  Vhost session is an infinite blocking loop.
>Put the session in a dedicate DPDK thread.
> 
>  *   Callback register
> @@ -73,6 +76,8 @@ Vhost API Overview
>  Vhost Implementation
>  
> 
> +Vhost cuse implementation
> +~
>  When vSwitch registers the vhost driver, it will register a cuse device 
> driver
> into the system and creates a character device file. This cuse driver will
> receive vhost open/release/IOCTL message from QEMU simulator.
> @@ -89,13 +94,40 @@ which means vhost could access the shared virtio ring
> and the guest physical  address specified in the entry of the ring.
> 
>  The guest virtual machine tells the vhost whether the virtio device is ready 
> -
> for processing or is de-activated through VHOST_SET_BACKEND message.
> +for processing or is de-activated through VHOST_NET_SET_BACKEND
> message.
>  The registered callback from vSwitch will be called.
> 
>  When the release call is released, vhost will destroy the device.
> 
> +Vhost user implementation
> +~
> +When vSwitch registers a vhost driver, it will create a unix domain
> +socket server into the system. This server will listen for a connection
> +and process the vhost message from QEMU simulator.
> +
> +When there is a new socket connection, it means a new virtio device has
> +been created in the guest virtual machine, and the vhost driver will create a
> vhost device for this virtio device.
> +
> +For messages with a file descriptor, the file descriptor could be
> +directly used in the vhost process as it is already installed by unix domain
> socket.
> + * VHOST_SET_MEM_TABLE
> + * VHOST_SET_VRING_KICK
> + * VHOST_SET_VRING_CALL
> + * VHOST_SET_LOG_FD
> + * VHOST_SET_VRING_ERR
> +
> +For VHOST_SET_MEM_TABLE message, QEMU will send us information for
> each
> +memory region and its file descriptor in the ancillary data of the message.
> The fd is used to map that region.
> +
> +There is no VHOST_NET_SET_BACKEND message as in vhost cuse to signal
> us
> +whether virtio device is ready or should be stopped.
> +VHOST_SET_VRING_KICK is used as the signal to put the vhost device onto
> data plane.
> +VHOST_GET_VRING_BASE is used as the signal to remove vhost device
> from data plane.
> +
> +When the socket connection is closed, vhost will destroy the device.
> +
>  Vhost supported vSwitch reference
>  -
> 
> -For how to support vhost in vSwitch, please refer to vhost example in the
> +For more vhost details and how to support vhost in vSwitch, please
> +refer to vhost example in the
>  DPDK Sample Applications Guide.
> --
> 1.8.1.4

Hi Huawei,

Having some issues with trailing 

[dpdk-dev] tools brainstorming

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, March 20, 2015 2:51 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] tools brainstorming
> 
> Hi,
> 
> As you probably know, a MAINTAINERS file is being filled, which is a great
> help to request patch reviews and discuss design with the knowledgeable
> people of this young DPDK community:
>   http://dpdk.org/browse/dpdk/tree/MAINTAINERS
> 
> The next step is to clearly define what are the guidelines to review a patch
> and accept it. So let's write a new document CONTRIBUTING (or another
> capitalized file ;). It will help contributors to do the right checks before
> submitting, and will help reviewers.
> 
> As we are lazy developers, writing guidelines is not enough. It must be
> coupled with the integration of some tools. Let's work on these ones:
>   - make autotests easier and faster to run for smoke testing
>   - automated basic testpmd check
>   - build check with various options combinations
>   - abi check (started with validate-abi.sh)
>   - static analyze (clang, free online coverity)
>   - comment check (doxygen, codespell, kerspell)
>   - format check (customized checkpatch)

This is a great list Thomas, totally agree with you we need some guidelines,
and some ways of automating basic checks to catch basic issues,
save time and traffic on the mailing list.

I propose we also add a bug tracking tool (e.g. Bugzilla or other).

And also a standalone page/document/archive of FAQ's.

> 
> I'm sure this last item will trigger a lot of debate.
> Actually, format checking can be of two kinds:
>   - commit message formatting (how to write the title, how and when
> adding
>   Fixes tag, Signed-off-by tag, etc);
>   - coding style might deserve its own document.
> 
> At the end, we should be able to pass a "make check" on the whole code and
> a "make checkpatch" before submitting.
> Then the result of these tools could be automatically checked and displayed
> in patchwork or in an adapted version of qemu's patchew. But this is
> obviously a later step.
> When all automatic lights are green and human design review is properly
> done, the patch can be acknowledged by one or many reviewers. Speaking
> about that, it would be helpful to have a column in our patchwork to
> summarize the counts of tests, reviews and acknowledgements.
> 
> Comments and contributions are more than welcome!

[dpdk-dev] [PATCH v2 1/3] doc: fix file attributes

[Butler, Siobhan A]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, March 19, 2015 4:48 PM
> To: Butler, Siobhan A; Iremonger, Bernard
> Cc: dev at dpdk.org
> Subject: [PATCH v2 1/3] doc: fix file attributes
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  doc/guides/prog_guide/i40e_ixgbe_igb_virt_func_drv.rst | 0
>  doc/guides/prog_guide/poll_mode_drv.rst| 0
>  2 files changed, 0 insertions(+), 0 deletions(-)  mode change 100755 =>
> 100644 doc/guides/prog_guide/i40e_ixgbe_igb_virt_func_drv.rst
>  mode change 100755 => 100644 doc/guides/prog_guide/poll_mode_drv.rst
> 
> diff --git a/doc/guides/prog_guide/i40e_ixgbe_igb_virt_func_drv.rst
> b/doc/guides/prog_guide/i40e_ixgbe_igb_virt_func_drv.rst
> old mode 100755
> new mode 100644
> diff --git a/doc/guides/prog_guide/poll_mode_drv.rst
> b/doc/guides/prog_guide/poll_mode_drv.rst
> old mode 100755
> new mode 100644
> --
> 2.2.2

Acked-by Siobhan Butler 

[dpdk-dev] [PATCH v2 2/3] doc: move Xen guide out of programmers guide

[Butler, Siobhan A]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, March 19, 2015 4:49 PM
> To: Butler, Siobhan A; Iremonger, Bernard
> Cc: dev at dpdk.org
> Subject: [PATCH v2 2/3] doc: move Xen guide out of programmers guide
> 
> Xen is an environment comparable to Linux and FreeBSD which have their
> own guide.
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  MAINTAINERS|   2 +-
>  doc/guides/index.rst   |   1 +
>  doc/guides/prog_guide/index.rst|   1 -
>  .../img/dpdk_xen_pkt_switch.png| Bin
>  doc/guides/{prog_guide => xen}/img/grant_refs.png  | Bin
> doc/guides/{prog_guide => xen}/img/grant_table.png | Bin
>  doc/guides/{ => xen}/index.rst |  21 
> +
>  .../pkt_switch.rst}|   0
>  8 files changed, 11 insertions(+), 14 deletions(-)  rename
> doc/guides/{prog_guide => xen}/img/dpdk_xen_pkt_switch.png (100%)
> rename doc/guides/{prog_guide => xen}/img/grant_refs.png (100%)
> rename doc/guides/{prog_guide => xen}/img/grant_table.png (100%)  copy
> doc/guides/{ => xen}/index.rst (88%)  rename
> doc/guides/{prog_guide/intel_dpdk_xen_based_packet_switch_sol.rst =>
> xen/pkt_switch.rst} (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bef7f59..24f0a4c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -132,9 +132,9 @@ F: lib/librte_eal/linuxapp/eal/*xen*
>  F: lib/librte_eal/linuxapp/eal/include/exec-env/rte_dom0_common.h
>  F: lib/librte_mempool/rte_dom0_mempool.c
>  F: lib/librte_pmd_xenvirt/
> +F: doc/guides/xen/
>  F: app/test-pmd/mempool_*
>  F: examples/vhost_xen/
> -F: doc/guides/prog_guide/intel_dpdk_xen_based_packet_switch_sol.rst
> 
>  FreeBSD EAL (with overlaps)
>  M: Bruce Richardson  diff --git
> a/doc/guides/index.rst b/doc/guides/index.rst index c589a30..53f1be1
> 100644
> --- a/doc/guides/index.rst
> +++ b/doc/guides/index.rst
> @@ -39,6 +39,7 @@ Contents:
> 
> linux_gsg/index
> freebsd_gsg/index
> +   xen/index
> prog_guide/index
> sample_app_ug/index
> testpmd_app_ug/index
> diff --git a/doc/guides/prog_guide/index.rst
> b/doc/guides/prog_guide/index.rst index 3c17e8d..b263d31 100644
> --- a/doc/guides/prog_guide/index.rst
> +++ b/doc/guides/prog_guide/index.rst
> @@ -53,7 +53,6 @@ Programmer's Guide
>  ivshmem_lib
>  poll_mode_drv_emulated_virtio_nic
>  poll_mode_drv_paravirtual_vmxnets_nic
> -intel_dpdk_xen_based_packet_switch_sol
>  libpcap_ring_based_poll_mode_drv
>  link_bonding_poll_mode_drv_lib
>  mlx4_poll_mode_drv
> diff --git a/doc/guides/prog_guide/img/dpdk_xen_pkt_switch.png
> b/doc/guides/xen/img/dpdk_xen_pkt_switch.png
> similarity index 100%
> rename from doc/guides/prog_guide/img/dpdk_xen_pkt_switch.png
> rename to doc/guides/xen/img/dpdk_xen_pkt_switch.png
> diff --git a/doc/guides/prog_guide/img/grant_refs.png
> b/doc/guides/xen/img/grant_refs.png
> similarity index 100%
> rename from doc/guides/prog_guide/img/grant_refs.png
> rename to doc/guides/xen/img/grant_refs.png diff --git
> a/doc/guides/prog_guide/img/grant_table.png
> b/doc/guides/xen/img/grant_table.png
> similarity index 100%
> rename from doc/guides/prog_guide/img/grant_table.png
> rename to doc/guides/xen/img/grant_table.png
> diff --git a/doc/guides/index.rst b/doc/guides/xen/index.rst similarity index
> 88% copy from doc/guides/index.rst copy to doc/guides/xen/index.rst index
> c589a30..628ecc3 100644
> --- a/doc/guides/index.rst
> +++ b/doc/guides/xen/index.rst
> @@ -28,18 +28,15 @@
>  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
>  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> 
> -DPDK documentation
> -==
> +Xen Guide
> +=
> 
> -Contents:
> +|today|
> +
> +**Contents**
> 
>  .. toctree::
> -   :maxdepth: 1
> -   :titlesonly:
> -
> -   linux_gsg/index
> -   freebsd_gsg/index
> -   prog_guide/index
> -   sample_app_ug/index
> -   testpmd_app_ug/index
> -   rel_notes/index
> +:maxdepth: 2
> +:numbered:
> +
> +pkt_switch
> diff --git
> a/doc/guides/prog_guide/intel_dpdk_xen_based_packet_switch_sol.rst
> b/doc/guides/xen/pkt_switch.rst similarity index 100% rename from
> doc/guides/prog_guide/intel_dpdk_xen_based_packet_switch_sol.rst
> rename to doc/guides/xen/pkt_switch.rst
> --
> 2.2.2

Acked-by Siobhan Butler 

[dpdk-dev] [PATCH v2 3/3] doc: nics guide

[Butler, Siobhan A]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, March 19, 2015 4:49 PM
> To: Butler, Siobhan A; Iremonger, Bernard
> Cc: dev at dpdk.org
> Subject: [PATCH v2 3/3] doc: nics guide
> 
> Create nics guide by moving chapters about Intel and Mellanox NICs.
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  MAINTAINERS|  15 +-
>  doc/guides/index.rst   |   1 +
>  .../driver_vm_emul_dev.rst => nics/e1000em.rst}|   0
>  doc/guides/{prog_guide => nics}/img/console.png| Bin
>  .../{prog_guide => nics}/img/fast_pkt_proc.png | Bin
>  .../{prog_guide => nics}/img/forward_stats.png | Bin
>  .../{prog_guide => nics}/img/host_vm_comms.png | Bin
>  .../img/host_vm_comms_qemu.png | Bin
>  .../{prog_guide => nics}/img/inter_vm_comms.png| Bin
>  .../{prog_guide => nics}/img/perf_benchmark.png| Bin
>  .../{prog_guide => nics}/img/single_port_nic.png   | Bin
>  .../{prog_guide => nics}/img/vm_vm_comms.png   | Bin
>  .../{prog_guide => nics}/img/vmxnet3_int.png   | Bin
>  doc/guides/{prog_guide => nics}/img/vswitch_vm.png | Bin
>  doc/guides/{ => nics}/index.rst|  29 ++--
>  .../intel_vf.rst}  |   8 +-
>  doc/guides/nics/ixgbe.rst  | 184 
> +
>  .../mlx4_poll_mode_drv.rst => nics/mlx4.rst}   |   0
>  .../pcap_ring.rst} |   0
>  .../virtio.rst}|   4 +-
>  .../vmxnet3.rst}   |   0
>  doc/guides/prog_guide/index.rst|  17 --
>  doc/guides/prog_guide/poll_mode_drv.rst| 152 -
>  23 files changed, 217 insertions(+), 193 deletions(-)  rename
> doc/guides/{prog_guide/driver_vm_emul_dev.rst => nics/e1000em.rst}
> (100%)  rename doc/guides/{prog_guide => nics}/img/console.png (100%)
> rename doc/guides/{prog_guide => nics}/img/fast_pkt_proc.png (100%)
> rename doc/guides/{prog_guide => nics}/img/forward_stats.png (100%)
> rename doc/guides/{prog_guide => nics}/img/host_vm_comms.png (100%)
> rename doc/guides/{prog_guide => nics}/img/host_vm_comms_qemu.png
> (100%)  rename doc/guides/{prog_guide => nics}/img/inter_vm_comms.png
> (100%)  rename doc/guides/{prog_guide => nics}/img/perf_benchmark.png
> (100%)  rename doc/guides/{prog_guide => nics}/img/single_port_nic.png
> (100%)  rename doc/guides/{prog_guide => nics}/img/vm_vm_comms.png
> (100%)  rename doc/guides/{prog_guide => nics}/img/vmxnet3_int.png
> (100%)  rename doc/guides/{prog_guide => nics}/img/vswitch_vm.png
> (100%)  copy doc/guides/{ => nics}/index.rst (88%)  rename
> doc/guides/{prog_guide/i40e_ixgbe_igb_virt_func_drv.rst =>
> nics/intel_vf.rst} (99%)  create mode 100644 doc/guides/nics/ixgbe.rst
> rename doc/guides/{prog_guide/mlx4_poll_mode_drv.rst => nics/mlx4.rst}
> (100%)  rename
> doc/guides/{prog_guide/libpcap_ring_based_poll_mode_drv.rst =>
> nics/pcap_ring.rst} (100%)  rename
> doc/guides/{prog_guide/poll_mode_drv_emulated_virtio_nic.rst =>
> nics/virtio.rst} (99%)  rename
> doc/guides/{prog_guide/poll_mode_drv_paravirtual_vmxnets_nic.rst =>
> nics/vmxnet3.rst} (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 24f0a4c..0afb3f4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -213,15 +213,20 @@ F: lib/librte_pmd_enic/
> 
>  Intel e1000
>  F: lib/librte_pmd_e1000/
> +F: doc/guides/nics/e1000em.rst
> +F: doc/guides/nics/intel_vf.rst
> 
>  Intel ixgbe
>  M: Helin Zhang 
>  M: Konstantin Ananyev 
>  F: lib/librte_pmd_ixgbe/
> +F: doc/guides/nics/ixgbe.rst
> +F: doc/guides/nics/intel_vf.rst
> 
>  Intel i40e
>  M: Helin Zhang 
>  F: lib/librte_pmd_i40e/
> +F: doc/guides/nics/intel_vf.rst
> 
>  Intel fm10k
>  M: Jing Chen 
> @@ -230,12 +235,12 @@ F: lib/librte_pmd_fm10k/  Mellanox mlx4
>  M: Adrien Mazarguil 
>  F: lib/librte_pmd_mlx4/
> -F: doc/guides/prog_guide/mlx4_poll_mode_drv.rst
> +F: doc/guides/nics/mlx4.rst
> 
>  RedHat virtio
>  M: Changchun Ouyang 
>  F: lib/librte_pmd_virtio/
> -F: doc/guides/prog_guide/poll_mode_drv_emulated_virtio_nic.rst
> +F: doc/guides/nics/virtio.rst
>  F: lib/librte_vhost/
>  F: doc/guides/prog_guide/vhost_lib.rst
>  F: examples/vhost/
> @@ -244,16 +249,16 @@ F: doc/guides/sample_app_ug/vhost.rst
>  VMware vmxnet3
>  M: Yong Wang 
>  F: lib/librte_pmd_vmxnet3/
> -F: doc/guides/prog_guide/poll_mode_drv_paravirtual_vmxnets_nic.rst
> +F: doc/guides/nics/vmxnet3.rst
> 
>  PCAP PMD
>  F: lib

[dpdk-dev] [PATCH] maintainers: claim pcap pmd library

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mcnamara, John
> Sent: Thursday, March 19, 2015 8:36 AM
> To: Nicol?s Pernas Maradei; dev at dpdk.org; thomas.monjalon at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH] maintainers: claim pcap pmd library
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nicol?s Pernas
> > Maradei
> > Sent: Wednesday, March 18, 2015 9:25 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH] maintainers: claim pcap pmd library
> >
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -247,6 +247,7 @@ F: lib/librte_pmd_vmxnet3/
> >  F: doc/guides/prog_guide/poll_mode_drv_paravirtual_vmxnets_nic.rst
> >
> >  PCAP PMD
> > +M: Nicol?s Pernas Maradei 
> >  F: lib/librte_pmd_pcap/
> >  F: doc/guides/prog_guide/libpcap_ring_based_poll_mode_drv.rst
> 
> Thomas, could you add my name as co-maintainer. If necessary I can submit a
> separate patch.
> 
> 
> Acked-by: John McNamara 
> 
> --
Acked-by Siobhan Butler 

[dpdk-dev] [PATCH] maintainers: claim pcap pmd library

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nicol?s Pernas
> Maradei
> Sent: Wednesday, March 18, 2015 9:25 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] maintainers: claim pcap pmd library
> 
> Signed-off-by: Nicol?s Pernas Maradei
> 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bef7f59..4c780db 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -247,6 +247,7 @@ F: lib/librte_pmd_vmxnet3/
>  F: doc/guides/prog_guide/poll_mode_drv_paravirtual_vmxnets_nic.rst
> 
>  PCAP PMD
> +M: Nicol?s Pernas Maradei 
>  F: lib/librte_pmd_pcap/
>  F: doc/guides/prog_guide/libpcap_ring_based_poll_mode_drv.rst
> 
> --
> 1.9.1

Acked-by Siobhan Butler 

[dpdk-dev] [PATCH v2 0/2] doc: update doc for fm10k driver

[Butler, Siobhan A]

Acked-by Siobhan Butler 

On Mar 13, 2015 9:14 AM, "Chen, Jing D"  wrote:
From: "Chen Jing D(Mark)" 

Update programming guide and release notes for fm10k driver.

Changes in v2:
- Remove a punctuation.


Chen Jing D(Mark) (2):
  doc: update programmers guide for fm10k pmd driver
  doc: update release note for fm10k pmd driver

 .../prog_guide/i40e_ixgbe_igb_virt_func_drv.rst|   37 ++-
 doc/guides/prog_guide/source_org.rst   |1 +
 doc/guides/rel_notes/new_features.rst  |   20 +++
 3 files changed, 56 insertions(+), 2 deletions(-)

--
1.7.7.6

[dpdk-dev] [PATCH v2 2/2] doc: update release note for fm10k pmd driver

[Butler, Siobhan A]

Acked-by Siobhan Butler 

On Mar 13, 2015 9:14 AM, "Chen, Jing D"  wrote:
From: "Chen Jing D(Mark)" 

Add feature list for fm10k driver.

Signed-off-by: Chen Jing D(Mark) 
---
 doc/guides/rel_notes/new_features.rst |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index 2993b1e..a27e360 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -58,4 +58,24 @@ New Features

 *   Packet Distributor Sample Application

+*   Poll Mode Driver - PCIE host-interface of Intel Ethernet Switch FM1 
Series (librte_pmd_fm10k)
+
+*   Basic Rx/Tx functions for PF/VF
+
+*   Interrupt handling support for PF/VF
+
+*   Per queue start/stop functions for PF/VF
+
+*   Support Mailbox handling between PF/VF and PF/Switch Manager
+
+*   Receive Side Scaling (RSS) for PF/VF
+
+*   Scatter receive function for PF/VF
+
+*   Reta update/query for PF/VF
+
+*   VLAN filter set for PF
+
+*   Link status query for PF/VF
+
 For further features supported in this release, see Chapter 3 Supported 
Features.
--
1.7.7.6

[dpdk-dev] [PATCH] doc: update release notes description for new sample apps Updated release notes release description notes: - added new sample applications to list: Link Bonding, Skeleton, Callbacks

[Butler, Siobhan A]

Self-Nack - title mistake

> -Original Message-
> From: Butler, Siobhan A
> Sent: Thursday, March 12, 2015 11:36 AM
> To: dev at dpdk.org
> Cc: Butler, Siobhan A
> Subject: [PATCH] doc: update release notes description for new sample apps
> Updated release notes release description notes: - added new sample
> applications to list: Link Bonding,Skeleton, Callbacks, Jobstats - updated
> copyright date to 2015 - updated release nu...
> 
> Signed-off-by: Siobhan Butler 
> ---
>  doc/guides/rel_notes/rel_description.rst | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/rel_description.rst
> b/doc/guides/rel_notes/rel_description.rst
> index 49f32b9..2fb5379 100644
> --- a/doc/guides/rel_notes/rel_description.rst
> +++ b/doc/guides/rel_notes/rel_description.rst
> @@ -1,5 +1,5 @@
>  ..  BSD LICENSE
> -Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> +Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
>  All rights reserved.
> 
>  Redistribution and use in source and binary forms, with or without @@ -
> 32,7 +32,7 @@ Description of Release  ==
> 
>  These release notes cover the new features, -fixed bugs and known issues
> for Data Plane Development Kit (DPDK) release version 1.7.0.
> +fixed bugs and known issues for Data Plane Development Kit (DPDK)
> release version 2.0.
> 
>  For instructions on compiling and running the release, see the *DPDK
> Getting Started Guide*.
> 
> @@ -103,6 +103,8 @@ The following is a list of DPDK documents in the
> suggested reading order:
> 
>  *   IP Reassembly
> 
> +*   IP Pipeline
> +
>  *   IP Fragmentation
> 
>  *   IPv4 Multicast
> @@ -111,6 +113,8 @@ The following is a list of DPDK documents in the
> suggested reading order:
> 
>  *   L2 Forwarding IVSHMEM
> 
> +*   L2 Forwarding Jobstats
> +
>  *   L3 Forwarding
> 
>  *   L3 Forwarding with Access Control
> @@ -119,6 +123,8 @@ The following is a list of DPDK documents in the
> suggested reading order:
> 
>  *   L3 Forwarding in a Virtualized Environment
> 
> +*   Link Bonding
> +
>  *   Link Status Interrupt
> 
>  *   Load Balancing
> @@ -149,6 +155,10 @@ The following is a list of DPDK documents in the
> suggested reading order:
> 
>  *   Distributor
> 
> +*   RX-TX Callbacks
> +
> +*   Skeleton
> +
>  In addition, there are some other applications that are built when the
> libraries are created.
>  The source for these applications is in the DPDK/app directory and are
> called:
> 
> @@ -163,6 +173,6 @@ The following is a list of DPDK documents in the
> suggested reading order:
>  *   The testpmd application provides a number of different packet
> throughput tests and examples of features such as
>  how to use the Flow Director found in the Intel? 82599 10 Gigabit
> Ethernet Controller.
> 
> -The testpmd application is documented in the *DPDK Testpmd Application
> Note* (525362).
> +The testpmd application is documented in the *DPDK Testpmd
> Application Note*.
>  The test application is not currently documented.
>  However, you should be able to run and use test application with the
> command line help that is provided in the application.
> --
> 1.8.3.1

[dpdk-dev] [PATCH] doc: add l2fwd-jobstats user guide

[Butler, Siobhan A]

> -Original Message-
> From: Wodkowski, PawelX
> Sent: Wednesday, March 11, 2015 9:42 AM
> To: dev at dpdk.org
> Cc: Butler, Siobhan A
> Subject: [PATCH] doc: add l2fwd-jobstats user guide
> 
> Signed-off-by: Pawel Wodkowski 
> ---
>  doc/guides/sample_app_ug/index.rst|   1 +
>  doc/guides/sample_app_ug/l2_forward_job_stats.rst | 637
> ++
>  2 files changed, 638 insertions(+)
>  create mode 100644 doc/guides/sample_app_ug/l2_forward_job_stats.rst
> 
> diff --git a/doc/guides/sample_app_ug/index.rst
> b/doc/guides/sample_app_ug/index.rst
> index 5720181..c89a2f0 100644
> --- a/doc/guides/sample_app_ug/index.rst
> +++ b/doc/guides/sample_app_ug/index.rst
> @@ -47,6 +47,7 @@ Sample Applications User Guide
>  ipv4_multicast
>  ip_reassembly
>  kernel_nic_interface
> +l2_forward_job_stats
>  l2_forward_real_virtual
>  l3_forward
>  l3_forward_power_man
> diff --git a/doc/guides/sample_app_ug/l2_forward_job_stats.rst
> b/doc/guides/sample_app_ug/l2_forward_job_stats.rst
> new file mode 100644
> index 000..76cea71
> --- /dev/null
> +++ b/doc/guides/sample_app_ug/l2_forward_job_stats.rst
> @@ -0,0 +1,637 @@
> +..  BSD LICENSE
> +Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions
> +are met:
> +
> +* Redistributions of source code must retain the above copyright
> +notice, this list of conditions and the following disclaimer.
> +* Redistributions in binary form must reproduce the above copyright
> +notice, this list of conditions and the following disclaimer in
> +the documentation and/or other materials provided with the
> +distribution.
> +* Neither the name of Intel Corporation nor the names of its
> +contributors may be used to endorse or promote products derived
> +from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> +
> +L2 Forwarding Sample Application (in Real and Virtualized Environments)
> with core load statistics.
> +=
> ==
> +===
> +
> +The L2 Forwarding sample application is a simple example of packet
> +processing using the Data Plane Development Kit (DPDK) which also takes
> +advantage of Single Root I/O Virtualization (SR-IOV) features in a 
> virtualized
> environment.
> +
> +.. note::
> +
> +This application is a variation of L2 Forwarding sample application. It
> demonstrate possible
> +scheme of job stats library usage therefore some parts of this document
> is identical with original
> +L2 forwarding application.
> +
> +Overview
> +
> +
> +The L2 Forwarding sample application, which can operate in real and
> +virtualized environments, performs L2 forwarding for each packet that is
> received.
> +The destination port is the adjacent port from the enabled portmask,
> +that is, if the first four ports are enabled (portmask 0xf), ports 1
> +and 2 forward into each other, and ports 3 and 4 forward into each other.
> +Also, the MAC addresses are affected as follows:
> +
> +*   The source MAC address is replaced by the TX port MAC address
> +
> +*   The destination MAC address is replaced by  02:00:00:00:00:TX_PORT_ID
> +
> +This application can be used to benchmark performance using a traffic-
> generator, as shown in the Figure 3.
> +
> +The application can also be used in a virtualized environment as shown in
> Figure 4.
> +
> +The L2 Forwarding application can also be used as a starting point for
> developing a new application based on the DPDK.
> +
> +

[dpdk-dev] [PATCH v3 2/2] doc: Update for new HW vlan command

[Butler, Siobhan A]

> -Original Message-
> From: Ouyang, Changchun
> Sent: Friday, March 6, 2015 8:10 AM
> To: dev at dpdk.org
> Cc: Butler, Siobhan A; De Lara Guarch, Pablo; Cao, Waterman; Ouyang,
> Changchun
> Subject: [PATCH v3 2/2] doc: Update for new HW vlan command
> 
> Update the testpmd doc as there are new HW VLAN commands/options.
> 
> Signed-off-by: Changchun Ouyang 
> ---
>  doc/guides/testpmd_app_ug/run_app.rst   | 12 +++
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst | 33
> +
>  2 files changed, 45 insertions(+)
> 
> diff --git a/doc/guides/testpmd_app_ug/run_app.rst
> b/doc/guides/testpmd_app_ug/run_app.rst
> index 67f62d2..3898e67 100644
> --- a/doc/guides/testpmd_app_ug/run_app.rst
> +++ b/doc/guides/testpmd_app_ug/run_app.rst
> @@ -262,6 +262,18 @@ They must be separated from the EAL options,
> shown in the previous section, with
> 
>  Disable hardware VLAN.
> 
> +*   --disable-hw-vlan-filter
> +
> +Disable hardware VLAN filter.
> +
> +*   --disable-hw-vlan-strip
> +
> +Disable hardware VLAN strip.
> +
> +*   --disable-hw-vlan-extend
> +
> +Disable hardware VLAN extend.
> +
>  *   --enable-drop-en
> 
>  Enable per-queue packet drop for packets with no descriptors.
> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index 218835a..b644626 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -896,6 +896,39 @@ Hardware VLAN is on by default.
> 
>  The off option is equivalent to the --disable-hw-vlan command-line option.
> 
> +port config - VLAN filter
> +~
> +
> +Set hardware VLAN filter on or off for all ports:
> +
> +port config all hw-vlan-filter (on|off)
> +
> +Hardware VLAN filter is on by default.
> +
> +The off option is equivalent to the --disable-hw-vlan-filter command-line
> option.
> +
> +port config - VLAN strip
> +
> +
> +Set hardware VLAN strip on or off for all ports:
> +
> +port config all hw-vlan-strip (on|off)
> +
> +Hardware VLAN strip is on by default.
> +
> +The off option is equivalent to the --disable-hw-vlan-strip command-line
> option.
> +
> +port config - VLAN extend
> +~
> +
> +Set hardware VLAN extend on or off for all ports:
> +
> +port config all hw-vlan-extend (on|off)
> +
> +Hardware VLAN extend is off by default.
> +
> +The off option is equivalent to the --disable-hw-vlan-extend command-line
> option.
> +
>  port config - Drop Packets
>  ~~
> 
> --
> 1.8.4.2

Acked-by Siobhan Butler 

[dpdk-dev] [PATCH v1] doc: prog guide update for eal multi-pthread

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming Liang
> Sent: Monday, February 16, 2015 7:34 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v1] doc: prog guide update for eal multi-pthread
> 
> The patch add the multi-pthread section under EAL chapter of prog_guide.
> 
> Signed-off-by: Cunming Liang 
> ---
>  doc/guides/prog_guide/env_abstraction_layer.rst | 157
> 
>  1 file changed, 157 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst
> b/doc/guides/prog_guide/env_abstraction_layer.rst
> index 231e266..06bcfae 100644
> --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> @@ -212,4 +212,161 @@ Memory zones can be reserved with specific start
> address alignment by supplying  The alignment value should be a power of
> two and not less than the cache line size (64 bytes).
>  Memory zones can also be reserved from either 2 MB or 1 GB hugepages,
> provided that both are available on the system.
> 
> +
> +Multiple pthread
> +
> +
> +DPDK usually pin one pthread per core to avoid task switch overhead. It
> +gains performance a lot, but it's not flexible and not always efficient.
> +
> +Power management helps to improve the cpu efficient by limiting the cpu
> runtime frequency.
> +But there's more reasonable motivation to utilize the ineffective idle cycles
> under the full capability of cpu.
> +
> +By OS scheduing and cgroup, to each pthread on specified cpu, it can simply
> assign the cpu quota.
> +It gives another way to improve the cpu efficiency. But the prerequisite is 
> to
> run DPDK execution conext from multiple pthread on one core.
> +
> +For flexibility, it's also useful to allow the pthread affinity not only to 
> a cpu
> but to a cpu set.
> +
> +
> +EAL pthread and lcore Affinity
> +~~
> +
> +In terms of lcore, it stands for an EAL execution unit in the EAL pthread.
> +EAL pthread indicates all the pthreads created/managed by EAL, they
> execute the tasks issued by *remote_launch*.
> +In each EAL pthread, there's a TLS called *_lcore_id* for the unique
> identification.
> +As EAL pthreads usually 1:1 bind to the physical cpu, *_lcore_id* typically
> equals to the cpu id.
> +
> +In multiple pthread case, EAL pthread is no longer always bind to one
> specific physical cpu.
> +It may affinity to a cpuset. Then the *_lcore_id* won't always be the same
> as cpu id.
> +So there's an EAL long option '--lcores' defined to assign the cpu affinity 
> of
> lcores.
> +For a specified lcore id or id group, it allows to set the cpuset for that 
> EAL
> pthread.
> +
> +The format pattern:
> + --lcores='[@cpu_set][,[@cpu_set],...]'
> +
> +'lcore_set' and 'cpu_set' can be a single number, range or a group.
> +
> +A number is a "digit([0-9]+)"; a range is "-"; a group is
> "([,,...])".
> +
> +If not supply a '\@cpu_set', the value of 'cpu_set' uses the same value as
> 'lcore_set'.
> +
> +::
> +
> + For example, "--lcores='1,2@(5-7),(3-5)@(0,2),(0,6),7-8'" which
> means start 9 EAL thread;
> + lcore 0 runs on cpuset 0x41 (cpu 0,6);
> + lcore 1 runs on cpuset 0x2 (cpu 1);
> + lcore 2 runs on cpuset 0xe0 (cpu 5,6,7);
> + lcore 3,4,5 runs on cpuset 0x5 (cpu 0,2);
> + lcore 6 runs on cpuset 0x41 (cpu 0,6);
> + lcore 7 runs on cpuset 0x80 (cpu 7);
> + lcore 8 runs on cpuset 0x100 (cpu 8).
> +
> +By this option, for each given lcore id, the associated cpus can be assigned.
> +It's also compatible with the pattern of corelist('-l') option.
> +
> +non-EAL pthread support
> +~~~
> +
> +It allows to use DPDK execution context in any user pthread(aka. non-EAL
> pthread).
> +
> +In a non-EAL pthread, the *_lcore_id* is always LCORE_ID_ANY which
> means it's not an EAL thread along with a valid *_lcore_id*.
> +Then the libraries won't take *_lcore_id* as unique id. Instead of it,
> +some libraries use another alternative unique id(e.g. tid); some are totaly
> no impact; and some work with some limitation(e.g. timer, mempool).
> +
> +All these impacts are mentioned in :ref:`known_issue_label` section.
> +
> +Public Thread API
> +~
> +
> +There are two public API ``rte_thread_set_affinity()`` and
> ``rte_pthread_get_affinity()`` introduced for threads.
> +When they're used in any pthread context, the Thread Local Storage(TLS)
> will be set/get.
> +
> +Those TLS include *_cpuset* and *_socket_id*:
> +
> +**_cpuset* stores the cpus bitmap to which the pthread affinity.
> +
> +**_socket_id* stores the NUMA node of the cpuset. If the cpus in
> cpuset belong to different NUMA node, the *_socket_id* set to
> SOCKTE_ID_ANY.
> +
> +
> +.. _known_issue_label:
> +
> +Known Issues
> +
> +
> ++ rte_mempool
> +
> +  The rte_mempool uses a per-lcore cache inside mempool.
> +  For non-EAL pthread, ``rte_lcore_id()``

[dpdk-dev] proposal: remove separate doc tree

[Butler, Siobhan A]

Thank you Thomas 

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, March 4, 2015 9:07 PM
> To: Butler, Siobhan A
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] proposal: remove separate doc tree
> 
> 2015-02-11 14:28, Butler, Siobhan A:
> > Hi all,
> >
> > In creating documentation for DPDK 1.8.0 dpdk.org used a separate
> repository 'dpdk-doc' to work on the conversion of old documentation from
> PDF to .rst with sphinx for maintainability and usability purposes.
> > Now that the conversion has been complete and patches to the
> documentation can be made, I propose that we no longer need the
> additional repo and it should be removed.
> >
> > Many Thanks,
> > Siobhan Butler
> 
> OK, it's now removed.
> Thanks

[dpdk-dev] [PATCH v15 13/13] doc: Add port hotplug framework section to programmers guide

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> Sent: Wednesday, February 25, 2015 7:32 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v15 13/13] doc: Add port hotplug framework
> section to programmers guide
> 
> This patch adds a new section for describing port hotplug framework.
> 
> v15:
> - Fix function names like below.
>  - rte_eal_dev_attach() to rte_eth_dev_attach().
>  - rte_eal_dev_detach() to rte_eth_dev_detach().
> 
> Signed-off-by: Tetsuya Mukawa 
> ---
>  doc/guides/prog_guide/index.rst  |   1 +
>  doc/guides/prog_guide/port_hotplug_framework.rst | 110
> +++
>  2 files changed, 111 insertions(+)
>  create mode 100644 doc/guides/prog_guide/port_hotplug_framework.rst
> 
> diff --git a/doc/guides/prog_guide/index.rst
> b/doc/guides/prog_guide/index.rst index de69682..60a6ac5 100644
> --- a/doc/guides/prog_guide/index.rst
> +++ b/doc/guides/prog_guide/index.rst
> @@ -71,6 +71,7 @@ Programmer's Guide
>  packet_classif_access_ctrl
>  packet_framework
>  vhost_lib
> +port_hotplug_framework
>  source_org
>  dev_kit_build_system
>  dev_kit_root_make_help
> diff --git a/doc/guides/prog_guide/port_hotplug_framework.rst
> b/doc/guides/prog_guide/port_hotplug_framework.rst
> new file mode 100644
> index 000..fe6d72a
> --- /dev/null
> +++ b/doc/guides/prog_guide/port_hotplug_framework.rst
> @@ -0,0 +1,110 @@
> +..  BSD LICENSE
> +Copyright(c) 2015 IGEL Co.,Ltd. All rights reserved.
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions
> +are met:
> +
> +* Redistributions of source code must retain the above copyright
> +notice, this list of conditions and the following disclaimer.
> +* Redistributions in binary form must reproduce the above copyright
> +notice, this list of conditions and the following disclaimer in
> +the documentation and/or other materials provided with the
> +distribution.
> +* Neither the name of IGEL Co.,Ltd. nor the names of its
> +contributors may be used to endorse or promote products derived
> +from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> +
> +Port Hotplug Framework
> +==
> +
> +The Port Hotplug Framework provides DPDK applications with the ability
> +to attach and detach ports at runtime. Because the framework depends on
> +PMD implementation, the ports that PMDs cannot handle are out of scope
> +of this framework. Furthermore, after detaching a port from a DPDK
> +application, the framework doesn't provide a way for removing the devices
> from the system.
> +For the ports backed by a physical NIC, the kernel will need to support
> +PCI Hotplug feature.
> +
> +Overview
> +
> +
> +The basic requirements of the Port Hotplug Framework are:
> +
> +*   DPDK applications that use the Port Hotplug Framework must manage
> their
> +own ports.
> +
> +The Port Hotplug Framework is implemented to allow DPDK applications
> to
> +manage ports. For example, when DPDK applications call the port 
> attach
> +function, the attached port number is returned. DPDK applications can
> +also detach the port by port number.
> +
> +*   Kernel support is needed for attaching or detaching physical device
> +ports.
> +
> +To attach new physical device ports, the device will be recognized by
> +userspace driver I/O framework in kernel at first. Then DPDK
> +applications can call the Port Hotplug functions to attach the ports.
> +For detaching, steps are vice versa.
> +
> +*   Before detaching, they must be stopped and closed.
> +
> +DPDK applications must call "rte_eth_dev_stop()" and
> +"rte_eth_dev_close()" APIs before detaching ports. These functions
> will
> +start finalization sequence of the PMDs.
> +
> +*   The framework doesn't affect legacy DPDK applications behavior.
> +
> +If the Port Hot

[dpdk-dev] [PATCH 3/3] doc: add docs for the rxtx_callbacks sample app

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John McNamara
> Sent: Wednesday, February 25, 2015 7:46 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 3/3] doc: add docs for the rxtx_callbacks sample
> app
> 
> Added a sample application guide for the rxtx_callbacks app.
> 
> Signed-off-by: John McNamara 
> ---
>  MAINTAINERS |1 +
>  doc/guides/sample_app_ug/index.rst  |1 +
>  doc/guides/sample_app_ug/rxtx_callbacks.rst |  251
> +++
>  3 files changed, 253 insertions(+), 0 deletions(-)  create mode 100644
> doc/guides/sample_app_ug/rxtx_callbacks.rst
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 86c1c6b..2ddb312 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -443,6 +443,7 @@ F: doc/guides/sample_app_ug/quota_watermark.rst
>  M: Bruce Richardson 
>  M: John McNamara 
>  F: examples/rxtx_callbacks/
> +F: doc/guides/sample_app_ug/rxtx_callbacks.rst
> 
>  M: Bruce Richardson 
>  M: John McNamara  diff --git
> a/doc/guides/sample_app_ug/index.rst
> b/doc/guides/sample_app_ug/index.rst
> index 4e9d59b..4a86459 100644
> --- a/doc/guides/sample_app_ug/index.rst
> +++ b/doc/guides/sample_app_ug/index.rst
> @@ -44,6 +44,7 @@ Sample Applications User Guide
>  exception_path
>  hello_world
>  skeleton
> +rxtx_callbacks
>  ip_frag
>  ipv4_multicast
>  ip_reassembly
> diff --git a/doc/guides/sample_app_ug/rxtx_callbacks.rst
> b/doc/guides/sample_app_ug/rxtx_callbacks.rst
> new file mode 100644
> index 000..9df57ed
> --- /dev/null
> +++ b/doc/guides/sample_app_ug/rxtx_callbacks.rst
> @@ -0,0 +1,251 @@
> +..  BSD LICENSE
> +Copyright(c) 2015 Intel Corporation. All rights reserved.
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions
> +are met:
> +
> +* Redistributions of source code must retain the above copyright
> +notice, this list of conditions and the following disclaimer.
> +* Redistributions in binary form must reproduce the above copyright
> +notice, this list of conditions and the following disclaimer in
> +the documentation and/or other materials provided with the
> +distribution.
> +* Neither the name of Intel Corporation nor the names of its
> +contributors may be used to endorse or promote products derived
> +from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> +
> +
> +RX/TX Callbacks Sample Application
> +==
> +
> +The RX/TX Callbacks sample application is a packet forwarding
> +application that demonstrates the use of user defined callbacks on
> +received and transmitted packets. The application performs a simple
> +latency check, using callbacks, to determine the time packets spend within
> the application.
> +
> +In the sample application a user defined callback is applied to all
> +received packets to add a timestamp. A separate callback is applied to
> +all packets prior to transmission to calculate the elapsed time, in CPU 
> cycles.
> +
> +
> +Compiling the Application
> +-
> +
> +To compile the application export the path to the DPDK source tree and
> +go to the example directory:
> +
> +.. code-block:: console
> +
> +export RTE_SDK=/path/to/rte_sdk
> +
> +cd ${RTE_SDK}/examples/rxtx_callbacks
> +
> +
> +Set the target, for example:
> +
> +.. code-block:: console
> +
> +export RTE_TARGET=x86_64-native-linuxapp-gcc
> +
> +See the *DPDK Getting Started* Guide for possible ``RTE_TARGET`` values.
> +
> +The callbacks feature requires that the
> +``CONFIG_RTE_ETHDEV_RXTX_CALLBACKS``
> +setting is on in the ``config/common_`` config file that applies to the
> +target. This is generally on by default:
> +
> +.. code-block:: console
> +
> +CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
> +
> +Build the application as follows:
> +
> +.. code-block:: console
> +
> +make
> +
> +
> +Running the Application
> +---
> +
> +To run the example in a ``linu

[dpdk-dev] [PATCH 1/3] examples/skeleton: minor refactoring to help documentation

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John McNamara
> Sent: Wednesday, February 25, 2015 7:46 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/3] examples/skeleton: minor refactoring to
> help documentation
> 
> Minor refactoring and comments to make the sample app and code
> examples clearer for the sample app guide.
> 
> Signed-off-by: John McNamara 
> ---
>  examples/skeleton/basicfwd.c |   77
> +++---
>  1 files changed, 57 insertions(+), 20 deletions(-)
> 
> diff --git a/examples/skeleton/basicfwd.c b/examples/skeleton/basicfwd.c
> index 6aa931e..1bce6e7 100644
> --- a/examples/skeleton/basicfwd.c
> +++ b/examples/skeleton/basicfwd.c
> @@ -1,7 +1,7 @@
>  /*-
>   *   BSD LICENSE
>   *
> - *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> + *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
>   *   All rights reserved.
>   *
>   *   Redistribution and use in source and binary forms, with or without
> @@ -48,12 +48,14 @@
>  #define BURST_SIZE 32
> 
>  static const struct rte_eth_conf port_conf_default = {
> - .rxmode = { .max_rx_pkt_len = ETHER_MAX_LEN, },
> + .rxmode = { .max_rx_pkt_len = ETHER_MAX_LEN }
>  };
> 
> +/* basicfwd.c: Basic DPDK skeleton forwarding example. */
> +
>  /*
> - * Initialises a given port using global settings and with the rx buffers
> - * coming from the mbuf_pool passed as parameter
> + * Initializes a given port using global settings and with the RX
> + buffers
> + * coming from the mbuf_pool passed as a parameter.
>   */
>  static inline int
>  port_init(uint8_t port, struct rte_mempool *mbuf_pool) @@ -66,10 +68,12
> @@ port_init(uint8_t port, struct rte_mempool *mbuf_pool)
>   if (port >= rte_eth_dev_count())
>   return -1;
> 
> + /* Configure the Ethernet device. */
>   retval = rte_eth_dev_configure(port, rx_rings, tx_rings,
> &port_conf);
>   if (retval != 0)
>   return retval;
> 
> + /* Allocate and set up 1 RX queue per Ethernet port. */
>   for (q = 0; q < rx_rings; q++) {
>   retval = rte_eth_rx_queue_setup(port, q, RX_RING_SIZE,
>   rte_eth_dev_socket_id(port), NULL,
> mbuf_pool); @@ -77,6 +81,7 @@ port_init(uint8_t port, struct rte_mempool
> *mbuf_pool)
>   return retval;
>   }
> 
> + /* Allocate and set up 1 TX queue per Ethernet port. */
>   for (q = 0; q < tx_rings; q++) {
>   retval = rte_eth_tx_queue_setup(port, q, TX_RING_SIZE,
>   rte_eth_dev_socket_id(port), NULL); @@ -
> 84,33 +89,41 @@ port_init(uint8_t port, struct rte_mempool *mbuf_pool)
>   return retval;
>   }
> 
> - retval  = rte_eth_dev_start(port);
> + /* Start the Ethernet port. */
> + retval = rte_eth_dev_start(port);
>   if (retval < 0)
>   return retval;
> 
> + /* Display the port MAC address. */
>   struct ether_addr addr;
>   rte_eth_macaddr_get(port, &addr);
> - printf("Port %u MAC: %02"PRIx8" %02"PRIx8" %02"PRIx8
> - " %02"PRIx8" %02"PRIx8" %02"PRIx8"\n",
> + printf("Port %u MAC: %02" PRIx8 " %02" PRIx8 " %02" PRIx8
> +" %02" PRIx8 " %02" PRIx8 " %02" PRIx8 "\n",
>   (unsigned)port,
>   addr.addr_bytes[0], addr.addr_bytes[1],
>   addr.addr_bytes[2], addr.addr_bytes[3],
>   addr.addr_bytes[4], addr.addr_bytes[5]);
> 
> + /* Enable RX in promiscuous mode for the Ethernet device. */
>   rte_eth_promiscuous_enable(port);
> 
>   return 0;
>  }
> 
>  /*
> - * Main thread that does the work, reading from INPUT_PORT
> - * and writing to OUTPUT_PORT
> + * The lcore main. This is the main thread that does the work, reading
> + from
> + * an input port and writing to an output port.
>   */
> -static  __attribute__((noreturn)) void
> +static __attribute__((noreturn)) void
>  lcore_main(void)
>  {
>   const uint8_t nb_ports = rte_eth_dev_count();
>   uint8_t port;
> +
> + /*
> +  * Check that the port is on the same NUMA node as the polling
> thread
> +  * for best performance.
> +  */
>   for (port = 0; port < nb_ports; port++)
>   if (rte_eth_dev_socket_id(port) > 0 &&
>   rte_eth_dev_socket_id(port) !=
> @@ -121,15 +134,28 @@ lcore_main(void)
> 
>   printf("\nCore %u forwarding packets. [Ctrl+C to quit]\n",
>   rte_lcore_id());
> +
> + /* Run until the application is quit or killed. */
>   for (;;) {
> + /*
> +  * Receive packets on a port and forward them on the paired
> +  * port. The mapping is 0 -> 1, 1 -> 0, 2 -> 3, 3 -> 2, etc.
> +  */
>   for (port = 0; port < nb_ports; port++) {
> +
> + /* Get burst of RX packets, from f

[dpdk-dev] [PATCH v2] doc: Update prog guide for virtio

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ouyang Changchun
> Sent: Monday, March 2, 2015 8:41 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] doc: Update prog guide for virtio
> 
> This patch add contents for major change in single virtio implementation, also
> add back something for merge-able feature and promiscuous mode in virtio.
> 
> Signed-off-by: Changchun Ouyang 
> ---
> 
> Changes in v2
>   -- A few words adjusted.
> 
>  .../prog_guide/poll_mode_drv_emulated_virtio_nic.rst| 17
> +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/poll_mode_drv_emulated_virtio_nic.rst
> b/doc/guides/prog_guide/poll_mode_drv_emulated_virtio_nic.rst
> index b0a6250..aae32b6 100644
> --- a/doc/guides/prog_guide/poll_mode_drv_emulated_virtio_nic.rst
> +++ b/doc/guides/prog_guide/poll_mode_drv_emulated_virtio_nic.rst
> @@ -68,20 +68,29 @@ Features and Limitations of virtio PMD
> 
>  In this release, the virtio PMD driver provides the basic functionality of
> packet reception and transmission.
> 
> -*   This release does not support mergeable buffers per packet for
> performance reasons.
> -The packet size supported is from 64 to 1518.
> -rte_mbuf should be big enough to hold the whole packet.
> +*   It supports merge-able buffers per packet when receiving packets and
> scattered buffer per packet
> +when transmitting packets. The packet size supported is from 64 to 1518.
> +
> +*   It supports multicast packets and promiscuous mode.
> 
>  *   The descriptor number for the RX/TX queue is hard-coded to be 256 by
> qemu.
>  If given a different descriptor number by the upper application,
>  the virtio PMD generates a warning and fall back to the hard-coded value.
> 
> -*   Features such as mac/vlan filter are not supported.
> +*   Features of mac/vlan filter are supported, negotiation with
> vhost/backend are needed to support them.
> +When backend can't support vlan filter, virtio app on guest should 
> disable
> vlan filter to make sure
> +the virtio port is configured correctly. E.g. specify 
> '--disable-hw-vlan' in
> testpmd command line.
> 
>  *   RTE_PKTMBUF_HEADROOM should be defined larger than sizeof(struct
> virtio_net_hdr), which is 10 bytes.
> 
>  *   Virtio does not support runtime configuration.
> 
> +*   Virtio supports Link State interrupt.
> +
> +*   Virtio supports software vlan stripping and inserting.
> +
> +*   Virtio supports using port IO to get PCI resource when uio/igb_uio
> module is not available.
> +
>  Prerequisites
>  -
> 
> --
> 1.8.4.2


Acked-by: Siobhan Butler 

[dpdk-dev] [PATCH v3 3/3] doc: add librte_pmd_mlx4 documentation

[Butler, Siobhan A]

Thank you Adrien this is great.
Siobhan

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Wednesday, February 25, 2015 1:52 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v3 3/3] doc: add librte_pmd_mlx4
> documentation
> 
> This documentation covers implementation details, features and limitations,
> configuration, prerequisites and provides a usage example.
> 
> Signed-off-by: Adrien Mazarguil 
> ---
>  MAINTAINERS  |   1 +
>  doc/guides/prog_guide/index.rst  |   1 +
>  doc/guides/prog_guide/mlx4_poll_mode_drv.rst | 326
> +++
>  doc/guides/prog_guide/source_org.rst |   1 +
>  4 files changed, 329 insertions(+)
>  create mode 100644 doc/guides/prog_guide/mlx4_poll_mode_drv.rst
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d8b0fbc..ac61825 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -223,6 +223,7 @@ F: lib/librte_pmd_fm10k/  Mellanox mlx4
>  M: Adrien Mazarguil 
>  F: lib/librte_pmd_mlx4/
> +F: doc/guides/prog_guide/mlx4_poll_mode_drv.rst
> 
>  RedHat virtio
>  M: Changchun Ouyang  diff --git
> a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
> index de69682..87f6b35 100644
> --- a/doc/guides/prog_guide/index.rst
> +++ b/doc/guides/prog_guide/index.rst
> @@ -56,6 +56,7 @@ Programmer's Guide
>  intel_dpdk_xen_based_packet_switch_sol
>  libpcap_ring_based_poll_mode_drv
>  link_bonding_poll_mode_drv_lib
> +mlx4_poll_mode_drv
>  timer_lib
>  hash_lib
>  lpm_lib
> diff --git a/doc/guides/prog_guide/mlx4_poll_mode_drv.rst
> b/doc/guides/prog_guide/mlx4_poll_mode_drv.rst
> new file mode 100644
> index 000..35570c3
> --- /dev/null
> +++ b/doc/guides/prog_guide/mlx4_poll_mode_drv.rst
> @@ -0,0 +1,326 @@
> +..  BSD LICENSE
> +Copyright 2012-2015 6WIND S.A.
> +
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions
> +are met:
> +
> +* Redistributions of source code must retain the above copyright
> +notice, this list of conditions and the following disclaimer.
> +* Redistributions in binary form must reproduce the above copyright
> +notice, this list of conditions and the following disclaimer in
> +the documentation and/or other materials provided with the
> +distribution.
> +* Neither the name of 6WIND S.A. nor the names of its
> +contributors may be used to endorse or promote products derived
> +from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> +
> +MLX4 poll mode driver library
> +=
> +
> +The MLX4 poll mode driver library (**librte_pmd_mlx4**) implements
> +support for **Mellanox ConnectX-3** 10/40 Gbps adapters (EN 40, EN 10,
> +Pro EN 40) as well as their virtual functions (VF) in SR-IOV context.
> +
> +.. note::
> +
> +   Due to external dependencies, this driver is disabled by default. It must
> +   be enabled manually by setting ``CONFIG_RTE_LIBRTE_MLX4_PMD=y``
> and
> +   recompiling DPDK.
> +
> +Implementation details
> +--
> +
> +Most Mellanox ConnectX-3 devices provide two ports but expose a single
> +PCI bus address, thus unlike most drivers, librte_pmd_mlx4 registers
> +itself as a PCI driver that allocates one Ethernet device per detected port.
> +
> +For this reason, one cannot white/blacklist a single port without also
> +white/blacklisting the others on the same device.
> +
> +Besides its dependency on libibverbs (that implies libmlx4 and
> +associated kernel support), librte_pmd_mlx4 relies heavily on system
> +calls for control operations such as querying/updating the MTU and flow
> control parameters.
> +
> +For security reasons and robustness, this driver only deals with
> +virtual memory addresses. The way resources allocations are handled by
> +the kernel combined with hardware specifications that allow it to
> +handle virtual memory addresses directly ensure that DPDK applications
> +cannot access random physical memory (or memory that does not belo

[dpdk-dev] [PATCH] doc: Update prog guide for virtio

[Butler, Siobhan A]

Thank you Changchun some small wording changes noted below

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ouyang Changchun
> Sent: Monday, March 2, 2015 8:08 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: Update prog guide for virtio
> 
> This patch add contents for major change in single virtio implementation, also
> add back something for merge-able feature and promiscuous mode in virtio.
> 
> Signed-off-by: Changchun Ouyang 
> ---
>  .../prog_guide/poll_mode_drv_emulated_virtio_nic.rst| 17
> +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/poll_mode_drv_emulated_virtio_nic.rst
> b/doc/guides/prog_guide/poll_mode_drv_emulated_virtio_nic.rst
> index b0a6250..5073d2e 100644
> --- a/doc/guides/prog_guide/poll_mode_drv_emulated_virtio_nic.rst
> +++ b/doc/guides/prog_guide/poll_mode_drv_emulated_virtio_nic.rst
> @@ -68,20 +68,29 @@ Features and Limitations of virtio PMD
> 
>  In this release, the virtio PMD driver provides the basic functionality of
> packet reception and transmission.
> 
> -*   This release does not support mergeable buffers per packet for
> performance reasons.
> -The packet size supported is from 64 to 1518.
> -rte_mbuf should be big enough to hold the whole packet.
> +*   It supports merge-able buffers per packet when receiving packets and
> scattered buffer per packet
> +when transmitting packets. The packet size supported is from 64 to 1518.
> +
> +*   It supports multicast packets and promiscuous mode.
> 
>  *   The descriptor number for the RX/TX queue is hard-coded to be 256 by
> qemu.
>  If given a different descriptor number by the upper application,
>  the virtio PMD generates a warning and fall back to the hard-coded value.
> 
> -*   Features such as mac/vlan filter are not supported.
> +*   Features of mac/vlan filter are supported, it need negotiate with
> vhost/backend to support them.


Features of mac/vlan filter are supported, negotiation with
 vhost/backend are needed to support them.

> +When backend can't support vlan filter, virtio app on guest should 
> disable
> vlan filter to make sure
> +the virtio port is configured correctly. E.g. specify 
> '--disable-hw-vlan' in
> testpmd command line.
> 
>  *   RTE_PKTMBUF_HEADROOM should be defined larger than sizeof(struct
> virtio_net_hdr), which is 10 bytes.
> 
>  *   Virtio does not support runtime configuration.
> 
> +*   Virtio supports Link State interrupt.
> +
> +*   Virtio supports software vlan stripping and inserting.
> +
> +*   Virtio supports using port IO to get PCI resource when uio/igb_uio
> module is not available.
> +
>  Prerequisites
>  -
> 
> --
> 1.8.4.2

[dpdk-dev] Looking forward to DPDK 2.1

[Butler, Siobhan A]

Hi all,

The progress on DPDK 2.0 has been really positive and thanks to everyone for 
contributing and helping to grow our community. We now look onwards to DPDK 2.1 
planning which is due to release at the end of July, and we'd like to inform 
the community of the features that we hope to submit to that release. The 
current list of features, along with brief descriptions, is included below.

This list is provisional and will naturally change over the lifecycle of the 
release, and should be taken as guidance on what we hope to submit, not a 
commitment.

Our aim in providing this information now is to solicit input from the 
community. We'd like to make sure we avoid duplication or conflicts with work 
that others are planning, so please feel free to let the community know of any 
plans that you have for contributions to DPDK in this timeframe. This will 
allow us to build a complete picture and ensure we avoid duplication of effort. 
We have seen great community collaboration in DPDK 2.0 and hope that this will 
increase in 2.1.

I'm sure people will have questions, and will be looking for more information 
on these features. Further details will be provided by the individual 
developers over the next few months. We aim to provide early outlines of the 
features so that we can obtain community feedback as soon as possible. In 
addition, community calls can be arranged to discuss features as required.


2.1 (Q2 2015) DPDK Features:

* Cuckoo hash - Provide a new hash library based on the cuckoo hashing scheme 
(see http://www.cs.cmu.edu/~dongz/papers/cuckooswitch.pdf), which shall 
guarantee worst-case constant lookup time with a better memory utilization, 
compared to the current implementation.

* IEEE1588 Support for i40e - Support IEEE1588 Standard (PTP) for i40e   
Ethernet Controller

* Continued development of PCI Hot Plug - Add support for PCI Hotplug Framework 
in librte_pmd drivers (librte_pmd_ixgbe, librte_pmd_bond, librte_pmd_e1000, 
librte_pmd_i40e, librte_pmd_virtio, librte_pmd_vmxnet3)

* Packet Framework Enhancements - Enhancements to Packet Framework Port and 
Table Libraries, as well as IP Pipeline  Application, to include additional 
statistics, better pipeline encapsulation and CLI simplification.

* i40e DCB (ETS only) - Support DCB Enhanced Transmission Selection algorithm 
with i40e Ethernet controller.

* i40e Mirroring Rule - Add support for port mirroring using i40e Ethernet 
Controller.

* Additional FM10K Features - Add support for additional usage models for FM10K 
including: promiscuous mode, mac vlan filter, statistics, vlan offload (strip, 
insertion, dual), flow control, Tx offload (checksum).

* Dynamic Configuration of RSS on Bonded Slave devices - Support dynamic queues 
assignment for RX packets. Implementation for a bonding device will require 
multiple RX queues support on a bonding slave and its dynamic
reconfiguration.

* VXLAN Offload Sample Application - Provide a sample application to 
demonstrate the usage of VXLAN overlay encapsulation protocol in DPDK.

* Dynamic Memory Management - Add DPDK API's (Rte_free_unused_pages, 
rte_attach_pages, rte_detach_pages, rte_lazy_allocation) for Dynamic Memory 
Management for NFV use cases.


Thanks,
Siobhan Butler

[dpdk-dev] [PATCH 0/3] doc: ACL - add description for new features.

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Konstantin
> Ananyev
> Sent: Wednesday, February 18, 2015 4:29 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 0/3] doc: ACL - add description for new features.
> 
> Konstantin Ananyev (3):
>   doc: Add restrictions for ACL rule fields
>   doc: ACL - add description for different classification methods
>   doc: ACL - add description for max_size build parameter
> 
>  .../prog_guide/packet_classif_access_ctrl.rst  | 83
> --
>  1 file changed, 78 insertions(+), 5 deletions(-)
> 
> --
> 1.8.3.1

Series Acked-by: Siobhan Butler 

[dpdk-dev] proposal: remove separate doc tree

[Butler, Siobhan A]

Hi all,

In creating documentation for DPDK 1.8.0 dpdk.org used a separate repository 
'dpdk-doc' to work on the conversion of old documentation from PDF to .rst with 
sphinx for maintainability and usability purposes.
Now that the conversion has been complete and patches to the documentation can 
be made, I propose that we no longer need the additional repo and it should be 
removed.

Many Thanks,
Siobhan Butler

[dpdk-dev] Query on QEMU with DPDK

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Shankari
> Vaidyalingam
> Sent: Thursday, January 1, 2015 4:58 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Query on QEMU with DPDK
> 
> Hi
> 
> 
> I'd like to know whether QEMU comes as an integrated package along with
> DPDK 1.7.1 and 1..8.0 release.

Hi Shankari,

I just noticed you're question appears unanswered,  QEMU is not included in 
DPDK releases to date.

> I was able see QEMU along with OVS-dpdk in the older versions of DPDK
> package but not in the later releases.

Not entirely sure what you mean here.

> Also please let me know where I can get stepwise instructions for installing
> QEMU and executing DPDK programs in VMs provided by QEMU.

There is some documentation here that might help you:
http://dpdk.org/doc
> 
> Regards
> Shankari.V

Hope you get this working. 
Many Thanks
Siobhan

[dpdk-dev] deadline for 2.0 features proposal

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Tuesday, February 3, 2015 10:15 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] deadline for 2.0 features proposal
> 
> On Tue, Feb 03, 2015 at 09:24:28PM +0100, Thomas Monjalon wrote:
> > 2015-02-03 12:04, Bruce Richardson:
> > > On Tue, Feb 03, 2015 at 11:40:41AM +0100, Thomas Monjalon wrote:
> > > > Hi,
> > > >
> > > > These features were planned in the 2.0 roadmap but not submitted:
> > > > - cuckoo hash
Cuckoo hash will be done in 2.1 

> > > > - packet distributor (phase 2)
Packet distributor will be added to in 2.1

> > > > - bifurcated driver, assuming availability in Linux kernel
As this was not applied in the Linux Kernel it will not make 2.0 and will have 
to be redesigned for 2.1

> > > > - Broadcom driver
> > > > - Hyper-V driver

i40e features will be ongoing, Tim will update this with the 2.1 list when its 
ready.
> > > > - i40e QoS
> > > > - i40e IEEE1588
> > > > - i40e DCB
> > > > - i40e SR-IOV switching
> > > > - i40e port mirroring
> > > >
> > > > They are now in the 2.1 roadmap.
> > > > If you are working on one of these features or plan to do, please
> > > > confirm their status and the estimated integration window.
> > > >
> > > > Thanks
> > >
> > > There are no enhancements to the packet distributor lib which will
> > > be ready for inclusion inside the 2.0 timeframe.
> >
> > But there will be something new for 2.1?
> > What means "phase 2"?
> >
> > Thanks
> > --
> > Thomas
> 
> I'm currently doing some investigation work in this area, to see what ways we
> can improve performance or use other distribution schemes. Depending on
> what comes out of the investigations, there may or may not be
> improvements to push in the 2.1 timeframe. It's too early to know at this
> point.
> 
> Regards,
> /Bruce

[dpdk-dev] [PATCH v8 4/4] docs: Add ABI documentation

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Thursday, January 22, 2015 3:49 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v8 4/4] docs: Add ABI documentation
> 
> Adding a document describing rudimentary ABI policy and adding notice
> space for any deprecation announcements
> 
> Signed-off-by: Neil Horman 
> CC: Thomas Monjalon 
> CC: "Richardson, Bruce" 
> 
> ---
> Change notes:
> 
> v5) Updated documentation to add notes from Thomas M.
> 
> v6) Moved abi.txt to guides/rel_notes/abi.rst
> 
> v7) Updated abi.rst to integrate with index file
> Updated abi.rst to conform to rst formatting
> Updated abi.rst to include example deprecation notices.  Its not exactly 
> the
> language that Thomas indicated, but I think it makes the idea clear.
> 
> v8) Add missing file index.rst which was left out of the prior commit
> ---
>  doc/guides/rel_notes/abi.rst   | 40
> 
>  doc/guides/rel_notes/index.rst |  1 +
>  2 files changed, 41 insertions(+)
>  create mode 100644 doc/guides/rel_notes/abi.rst
> 
> diff --git a/doc/guides/rel_notes/abi.rst b/doc/guides/rel_notes/abi.rst new
> file mode 100644 index 000..73d88ca
> --- /dev/null
> +++ b/doc/guides/rel_notes/abi.rst
> @@ -0,0 +1,40 @@
> +ABI policy
> +==
> +ABI versions are set at the time of major release labeling, and ABI may
> +change multiple times between the last labeling and the HEAD label of
> +the git tree without warning.
> +
> +ABI versions, once released are available until such time as their
> +deprecation has been noted here for at least one major release cycle,
> +after it has been tagged.  E.g. the ABI for DPDK 1.8 is shipped, and
> +then the decision to remove it is made during the development of DPDK
> +1.9.  The decision will be recorded here, shipped with the DPDK 1.9
> +release, and actually removed when DPDK
> +1.10 ships.
> +
> +ABI versions may be deprecated in whole, or in part as needed by a given
> update.
> +
> +Some ABI changes may be too significant to reasonably maintain multiple
> +versions of.  In those events ABI's may be updated without backward
> +compatibility provided.  The requirements for doing so are:
> +
> +#. At least 3 acknoweldgements of the need on the dpdk.org #. A full
> +deprecation cycle must be made to offer downstream consumers sufficient
> +warning of the change.  E.g. if dpdk 2.0 is under development when the
> +change is proposed, a deprecation notice must be added to this file,
> +and released with dpdk 2.0.  Then the change may be incorporated for
> +dpdk 2.1 #. The LIBABIVER variable in the makefilei(s) where the ABI
> +changes are incorporated must be incremented in parallel with the ABI
> +changes themselves
> +
> +Note that the above process for ABI deprecation should not be
> +undertaken lightly.  ABI stability is extreemely important for
> +downstream consumers of the DPDK, especially when distributed in shared
> +object form.  Every effort should be made to preserve ABI whenever
> +possible.  For instance, reorganizing public structure field for
> +astetic or readability purposes should be avoided as it will cause ABI
> +breakage.  Only significant (e.g. performance) reasons should be seen as
> cause to alter ABI.
> +
> +Examples of Deprecation notices
> +---
> +* The Macro #RTE_FOO is deprecated and will be removed with version
> +2.0, to be replaced with the inline function rte_bar()
> +* The function rte_mbuf_grok has been updated to include new parameter
> +in version 2.0.  Backwards compatibility will be maintained for this
> +function until the release of version 2.1
> +* The members struct foo have been reorganized in release 2.0.  Existing
> binary applications will have backwards compatibility in release 2.0, while
> newly built binaries will need to reference new structure variant struct foo2.
> Compatibility will be removed in release 2.2, and all applications will 
> require
> updating a rebuilding to the new structure at that time, which will be
> renamed to the origional struct foo.
> +* Significant ABI changes are planned for the librte_dostuff library.  The
> upcomming release 2.0 will not contain these changes, but release 2.1 will,
> and no backwards compatibility is planned due to the invasive nature of
> these changes.  Binaries using this library built prior to version 2.1 will 
> require
> updating and recompilation.
> +
> +Deprecation Notices
> +---
> diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
> index 2724149..cf712b2 100644
> --- a/doc/guides/rel_notes/index.rst
> +++ b/doc/guides/rel_notes/index.rst
> @@ -48,4 +48,5 @@ Contents
>  updating_apps
>  known_issues
>  resolved_issues
> +abi
>  faq
> --
> 2.1.0

Acked-by: Siobhan Butler 

[dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation

[Butler, Siobhan A]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Tuesday, January 20, 2015 2:42 PM
> To: Butler, Siobhan A
> Cc: Iremonger, Bernard; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation
> 
> On Tue, Jan 20, 2015 at 02:29:54PM +, Butler, Siobhan A wrote:
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > > Sent: Tuesday, January 20, 2015 2:24 PM
> > > To: Iremonger, Bernard
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation
> > >
> > > On Tue, Jan 20, 2015 at 01:37:35PM +, Iremonger, Bernard wrote:
> > > > > -Original Message-
> > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas
> > > Monjalon
> > > > > Sent: Tuesday, January 20, 2015 7:15 AM
> > > > > To: Neil Horman
> > > > > Cc: dev at dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH v5 4/4] docs: Add ABI
> > > > > documentation
> > > > >
> > > > > Thank you Neil for writing this document.
> > > > > This is a really important change in DPDK.
> > > > > It would be very good to have comments or acknowledgement from
> > > > > several developpers. This policy would be enforced by having
> > > > > several
> > > Acked-by lines.
> > > > >
> > > > >
> > > > > 2015-01-16 10:33, Neil Horman:
> > > > > > Adding a document describing rudimentary ABI policy and adding
> > > > > > notice space for any deprecation announcements
> > > > > >
> > > > > > Signed-off-by: Neil Horman 
> > > > > > CC: Thomas Monjalon 
> > > > > > CC: "Richardson, Bruce" 
> > > > > >
> > > > > > ---
> > > > > > Change notes:
> > > > > >
> > > > > > v5) Updated documentation to add notes from Thomas M.
> > > > > > ---
> > > > > >  doc/abi.txt | 36 
> > > > > >  1 file changed, 36 insertions(+)  create mode 100644
> > > > > > doc/abi.txt
> > > > > >
> > > > > > diff --git a/doc/abi.txt b/doc/abi.txt new file mode 100644
> > > > > > index
> > > > > > 000..14be464
> > > > > > --- /dev/null
> > > > > > +++ b/doc/abi.txt
> > > > > > @@ -0,0 +1,36 @@
> > > > > > +ABI policy:
> > > > > > +   ABI versions are set at the time of major release labeling,
> > > > > > +and ABI may change multiple times between the last labeling
> > > > > > +and the HEAD label of the git tree without warning
> > > > > > +
> > > > > > +   ABI versions, once released are available until such time as
> > > > > > +their deprecation has been noted here for at least one major
> > > > > > +release cycle, after it has been tagged.  E.g. the ABI for
> > > > > > +DPDK
> > > > > > +1.8 is shipped, and then the decision to remove it is made
> > > > > > +during the development of DPDK 1.9.  The decision will be
> > > > > > +recorded here, shipped with the DPDK 1.9 release, and
> > > > > > +actually removed when DPDK
> > > > > > +1.10 ships.
> > > > > > +
> > > > > > +   ABI versions may be deprecated in whole, or in part as
> > > > > > +needed by a given update.
> > > > > > +
> > > > > > +   Some ABI changes may be too significant to reasonably
> > > > > > +maintain multiple versions of.  In those events ABI's may be
> > > > > > +updated without backward compatibility provided.  The
> > > > > > +requirements for doing
> > > so are:
> > > > > > +   1) At least 3 acknoweldgements of the need on the dpdk.org
> > > > > > +   2) A full deprecation cycle must be made to offer
> downstream
> > > > > > +consumers sufficient warning of the change.  E.g. if dpdk 2.0
> > > > > > +is under development when the change is proposed, a
> > > > > > +deprecation notice must be added to this file, and released with
> dpdk 2.0.
> > 

[dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Tuesday, January 20, 2015 2:24 PM
> To: Iremonger, Bernard
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation
> 
> On Tue, Jan 20, 2015 at 01:37:35PM +, Iremonger, Bernard wrote:
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas
> Monjalon
> > > Sent: Tuesday, January 20, 2015 7:15 AM
> > > To: Neil Horman
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation
> > >
> > > Thank you Neil for writing this document.
> > > This is a really important change in DPDK.
> > > It would be very good to have comments or acknowledgement from
> > > several developpers. This policy would be enforced by having several
> Acked-by lines.
> > >
> > >
> > > 2015-01-16 10:33, Neil Horman:
> > > > Adding a document describing rudimentary ABI policy and adding
> > > > notice space for any deprecation announcements
> > > >
> > > > Signed-off-by: Neil Horman 
> > > > CC: Thomas Monjalon 
> > > > CC: "Richardson, Bruce" 
> > > >
> > > > ---
> > > > Change notes:
> > > >
> > > > v5) Updated documentation to add notes from Thomas M.
> > > > ---
> > > >  doc/abi.txt | 36 
> > > >  1 file changed, 36 insertions(+)
> > > >  create mode 100644 doc/abi.txt
> > > >
> > > > diff --git a/doc/abi.txt b/doc/abi.txt new file mode 100644 index
> > > > 000..14be464
> > > > --- /dev/null
> > > > +++ b/doc/abi.txt
> > > > @@ -0,0 +1,36 @@
> > > > +ABI policy:
> > > > +   ABI versions are set at the time of major release labeling, and
> > > > +ABI may change multiple times between the last labeling and the
> > > > +HEAD label of the git tree without warning
> > > > +
> > > > +   ABI versions, once released are available until such time as
> > > > +their deprecation has been noted here for at least one major
> > > > +release cycle, after it has been tagged.  E.g. the ABI for DPDK
> > > > +1.8 is shipped, and then the decision to remove it is made during
> > > > +the development of DPDK 1.9.  The decision will be recorded here,
> > > > +shipped with the DPDK 1.9 release, and actually removed when DPDK
> > > > +1.10 ships.
> > > > +
> > > > +   ABI versions may be deprecated in whole, or in part as needed by
> > > > +a given update.
> > > > +
> > > > +   Some ABI changes may be too significant to reasonably maintain
> > > > +multiple versions of.  In those events ABI's may be updated
> > > > +without backward compatibility provided.  The requirements for doing
> so are:
> > > > +   1) At least 3 acknoweldgements of the need on the dpdk.org
> > > > +   2) A full deprecation cycle must be made to offer downstream
> > > > +consumers sufficient warning of the change.  E.g. if dpdk 2.0 is
> > > > +under development when the change is proposed, a deprecation
> > > > +notice must be added to this file, and released with dpdk 2.0.
> > > > +Then the change may be incorporated for
> > > dpdk 2.1
> > > > +   3) The LIBABIVER variable in the makefilei(s) where the ABI
> > > > +changes are incorporated must be incremented in parallel with the
> > > > +ABI changes themselves
> > > > +
> > > > +   Note that the above process for ABI deprecation should not be
> > > > +undertaken lightly.  ABI stability is extreemely important for
> > > > +downstream consumers of the DPDK, especially when distributed in
> > > > +shared object form.  Every effort should be made to preserve ABI
> > > > +whenever possible.  For instance, reorganizing public structure
> > > > +field for astetic or readability purposes should be avoided as it
> > > > +will cause ABI breakage.  Only significant (e.g. performance)
> > > > +reasons should be seen as cause to alter
> > > ABI.
> >
> > Hi Thomas,
> >
> > Should there be a reference to this document in the programmers guide?
> >
> Thats a good question. I think, as Thomas notes, it probably should be
> referenced in some way.  The programmers guide might be good.  What
> might be better would be checking the deprecation notices and adding them
> to the release notes for any given release.
> 
> Thoughts?
> Neil
> 
> > Regards,
> >
> > Bernard.
> >
> >

Sorry to be pedantic but would you also mind sending it as a .rst file instead 
of .txt if you're going to send as patches to Programmer's Guide anyway? :)
Thanks,
Siobhan

[dpdk-dev] [PATCH 0/3] pkg: update RPM recipe

[Butler, Siobhan A]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, December 19, 2014 3:12 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 0/3] pkg: update RPM recipe
> 
> Adjust RPM recipe for 1.8.0 release.
> 
> Thomas Monjalon (3):
>   pkg: fix link to bind tool
>   pkg: support sphinx documentation
>   pkg: remove Intel references
> 
>  pkg/dpdk-core.spec | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> --
> 2.1.3

Acked-by: Siobhan Butler 

[dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

[Butler, Siobhan A]

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Neil Horman
Sent: Friday, November 21, 2014 8:21 PM
To: O'driscoll, Tim
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Next Community Call, Tuesday 2nd December, 8:00 AM GMT

On Fri, Nov 21, 2014 at 04:08:53PM +, O'driscoll, Tim wrote:
> >We're going to hold our next community call on Tuesday 2nd December. This 
> >time, we're going to try a time that's more suitable for participants in 
> >Asia, so we're going to hold it at 8:00 AM GMT. The meeting time in a 
> >variety of timezones is included below.
> >
>> Generally, GoToMeeting worked well last time, although there was a 
>> limitation that Neil was unable to present slides as he joined from a Linux 
>> system. We'll stick with GoToMeeting again this time as we don't yet have a 
>> better solution. Details for joining the GoToMeeting session are included 
>> below.
> >
> I'll record the session again and post the video to YouTube afterwards for 
> anybody who can't make it. This seemed to work well last time, and as Kevin 
> pointed out, the audio quality on the recording is good.
> >
> >For the agenda, we'd like to discuss the following:
> >? Remaining 2.0 candidate features, especially PCI Hotplug as there's been a 
> >lot of discussion on that on the mailing list. Hopefully Tetsuya Mukawa can 
> >join us to describe his work on this.
> >? DPDK Test Suite. We hope to announce the release of this next week. 
> >Waterman Cao and Yong (Marvin) Liu from our Shanghai team will describe the 
> >functionality and benefits of this.
> >
> >
>> Meeting Time:
> >Dublin (Ireland) Tuesday, December 2, 2014 at 8:00:00 AM GMT UTC Paris 
> >(France) Tuesday, December 2, 2014 at 9:00:00 AM CET UTC+1 hour Tel 
> >Aviv (Israel) Tuesday, December 2, 2014 at 10:00:00 AM IST UTC+2 hours 
> >Moscow (Russia) Tuesday, December 2, 2014 at 11:00:00 AM MSK UTC+3 
> >hours New Delhi (India - Delhi) Tuesday, December 2, 2014 at 1:30:00 
> >PM IST UTC+5:30 hours Shanghai (China - Shanghai Municipality) 
>> Tuesday, December 2, 2014 at 4:00:00 PM CST UTC+8 hours Tokyo (Japan) 
>> Tuesday, December 2, 2014 at 5:00:00 PM JST UTC+9 hours San Francisco 
>> (U.S.A. - California) Midnight between Monday, December 1, 2014 and 
>> Tuesday, December 2, 2014 PST UTC-8 hours Phoenix (U.S.A. - Arizona) 
>> Tuesday, December 2, 2014 at 1:00:00 AM MST UTC-7 hours New York 
> >(U.S.A. - New York) Tuesday, December 2, 2014 at 3:00:00 AM EST UTC-5 
> >hours Ottawa (Canada - Ontario) Tuesday, December 2, 2014 at 3:00:00 
> >AM EST UTC-5 hours Corresponding UTC (GMT) Tuesday, December 2, 2014 
> >at 08:00:00
> >
>3am EST?  I presume this is made to accomodate Far east participants, correct?
>Neil

Exactly Neil, the hope is to alternate so that everyone gets an opportunity to 
participate :)

>> 
>> GoToMeeting Details:
>> To join, follow the meeting link: 
>> https://global.gotomeeting.com/join/772753069. This will start the 
>> GoToMeeting web viewer. You then have two options for audio:
>> 
> >1. To use your computer's audio via a headset, you need to switch to the 
> >desktop version of GoToMeeting. You can do this by clicking the GoToMeeting 
> >icon on the top right hand side of the web viewer, and then selecting 
> >"Switch to the desktop version". The desktop version will need to download 
> >and install, so if you plan to use this you may want to get it set up in 
> >advance. Once it starts, under the Audio section, you can select "Mic & 
> >Speakers". The desktop version is only available for Windows and Mac, so if 
> >you're using Linux then you need to use option 2 below.
> >
> >2. You can join using a phone via one of the numbers listed below. The 
> >Access Code is 772-753-069. You'll also be asked for an Audio PIN, which is 
> >accessible by clicking the phone icon in the GoToMeeting web viewer after 
> >you've joined the meeting.
> >? Australia   (Long distance): +61 2 9091 7601  
> >? Austria   (Long distance): +43 (0) 7 2088 1036  
> >? Belgium   (Long distance): +32 (0) 28 08 4345  
> >? Canada   (Long distance): +1 (647) 497-9372  
> >? Denmark   (Long distance): +45 (0) 69 91 89 24  
> >? Finland   (Long distance): +358 (0) 942 45 0382  
> >? France   (Long distance): +33 (0) 170 950 586  
> >? Germany   (Long distance): +49 (0) 692 5736 7206  
> >? Ireland   (Long distance): +353 (0) 15 255 598  
> >? Italy   (Long distance): +39 0 694 80 31 28  
> >? Netherlands   (Long distance): +31 (0) 208 084 055  
> >? New Zealand   (Long distance): +64 (0) 4 974 7243  
> >? Norway   (Long distance): +47 23 96 01 18  
> >? Spain   (Long distance): +34 932 20 0506  
> >? Sweden   (Long distance): +46 (0) 852 500 182  
> >? Switzerland   (Long distance): +41 (0) 435 0824 78  
> >? United Kingdom   (Long distance): +44 (0) 330 221 0098  
> >? United States   (Long distance): +1 (626) 521-0013
>> Access Code 772-753-069.   
> 
>> Info on downloading the desktop app is available at: 
> >http://support.citrixonline

[dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility

[Butler, Siobhan A]

From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Wednesday, October 8, 2014 4:57 PM
To: Neil Horman
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support 
backwards compatibility

Hi Neil,

2014-10-07 17:01, Neil Horman:
> On Wed, Oct 01, 2014 at 02:59:40PM -0400, Neil Horman wrote:
> > On Fri, Sep 26, 2014 at 10:45:49AM -0400, Neil Horman wrote:
> > > On Fri, Sep 26, 2014 at 12:41:33PM +0200, Thomas Monjalon wrote:
> > > > Hi Neil,
> > > > 
> > > > 2014-09-24 14:19, Neil Horman:
> > > > > Ping Thomas. I know you're busy, but I would like this to not 
> > > > > fall off anyones radar.  You alluded to concerns regarding 
> > > > > what, for lack of a better term, ABI/API lockin.  I had asked 
> > > > > you to enuumerate/elaborate on specifics, but never heard 
> > > > > back.  Are there further specifics you wish to discuss, or are you 
> > > > > satisfied with the above answers?
> > > > 
> > > > Sorry for not being very reactive on this thread.
> > > > All this discussion is very interesting but it's really not the 
> > > > proper time to apply it. As you said, it requires an extra 
> > > > effort. I'm not saying it will never be integrated. I'm just 
> > > > saying that we cannot change everything at the same time.
> > > > 
> > > > Let me sum up the situation. This community project has been 
> > > > very active for few months now. First, we learnt how to make 
> > > > some releases together and we are improving the process to be 
> > > > able to deliver a new major release every 4 months while having some 
> > > > good quality process.
> > > > But these releases are still not complete because documentation 
> > > > is not integrated yet. Then developers should have a role in 
> > > > documentation updates.
> > > > We also need to integrate and learn how to use more tools to be 
> > > > more efficient and improve quality.
> > > > 
> > > > So the question is "when should we care about API compatibility"?
> > > > And the answer is: ASAP, but not now. I feel next year is a better 
> > > > target.
> > > > Because the most important priority is to move together at a 
> > > > pace which allow most of us to stay in the race.
> > > 
> > > I'm sorry Thomas, I don't accept this.  I asked you for details as 
> > > to your concerns regarding this patch series, and you've provided more 
> > > vague comments.
> > > I need details to address
> > > 
> > > You say it requires extra effort, you're right it does.  Any 
> > > feature that you integreate requires some additional effort.  How 
> > > is this patch any different from adding the acl library or any 
> > > other new API?  Everything requires maintenence, thats how 
> > > software works.  What specfically about this patch series makes the 
> > > effort insurmountable to you?
> > > 
> > > You say you're improving your process.  Great, this patch aids in 
> > > that process by ensuring backwards compatibility for a period of 
> > > time.  Given that the API and ABI can still evolve within this 
> > > framework, as I've described, how is this patch series not a significant 
> > > step forward toward your goal of quality process.
> > > 
> > > You say documentation isn't integrated.  So, what does getting 
> > > documentation integrated have to do with this patch set, or any 
> > > other?  I don't see you holding any other patches based on 
> > > documentation.  Again, nothing in this series prevents evolution 
> > > of the API or ABI.  If you're hope is to wait until everything is 
> > > perfect, then apply some control to the public facing API, and get it all 
> > > documented, none of thosse things will ever happen, I promise you.
> > > 
> > > You say you also need to learn to use more tools to be more 
> > > efficient and improve quality.  Great!  Thats exactly what this 
> > > is. If we mandate even a short term commitment to ABI stability (1 
> > > single relese worth of time), we will quickly identify what API's 
> > > change quickly and where we need to be cautious with our API 
> > > design.  If you just assume that developers will get better of their own 
> > > volition, it will never happen.
> > > 
> > > You say this should go in next year, but not now.  When exactly?  
> > > What event do you forsee occuring in the next 12-18 months that 
> > > will change everything such that we can start supporing an ABI for 
> > > more than just a few weeks at the head of the tree?
> > > 
> > > To this end, I just did a quick search through the git history for 
> > > dpdk to look at the histories of all the header files that are 
> > > exposed via the makefile SYMLINK command (given that that provides 
> > > a list of header files that applications can include, and embodies 
> > > all the function symbols and data types applications have access to.
> > > 
> > > There are 179 total commits in that list Of those, a bit of spot 
> > > checking suggests that about 10-15% of them actually change ABI, 
> > > and m

[dpdk-dev] Licensing consistency

[Butler, Siobhan A]

>-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
>Sent: Thursday, June 5, 2014 7:57 PM
>To: dev at dpdk.org
>Subject: [dpdk-dev] Licensing consistency
>
>Hey all-
>   One of the things that came up during the dpdk package review for 
> Fedora was the inconsistency of License reporting in the upstream project.  
> DPDK is >triple licensed, whcih isn't in and of itself a big deal, but 
> indications of which file(s) are under which license is fairly scattered.  
> For instance:
>
>1) The kni module has a GPLv2 license at the top of each file
>
>2) The kni MODULE_LICENSE macro indicates the license is dual BSD/GPLv2
>
>3) The rte_kni_common.h file is licensed dual BSD/LGPL v2
>
>4) The linux kernel modules for hardware pmds have no license file in them at 
>all, but do have a README which contains a BSD license (though no clear 
>>indicator that this license applies to the files in this directory).
>
>
>Theres several more examples of this, but the point is, its often not clear 
>what bits fall under what license.  Has any effort been made to consolodate 
>licensing >here, or at least to make it consistent and clear where to find 
>license information for a file?  If not I would propose that all files in the 
>DPDK be required to >carry the license that they are distributed under in the 
>top of said file, and that we add a LICENSE file to the tree root indicating 
>that each file contains its own >licensing terms.
>
>Thoughts?
>Neil

Hi Neil, 
I think you highlight some important points here regarding the need for 
vigilance in licensing each part of the software and it is something we should 
all be aware of when contributing to dpdk.org. 

I can assure you during the development of the features thus far, a great deal 
of thought and care was applied in regard to keeping the number of varying 
license to a minimum and to ensure that each one is correct for purpose. 
Changes to the licensing made over time have been carefully considered at each 
change.

In relation to the files that have not got the license in the actual file but 
instead in the corresponding Readme file - the license applies to the files in 
the 
directory unless otherwise clearly stated in the file itself. If you have some 
suggestions as to how consistency can be better achieved as the community grows 
and develops that would be great.

Thanks
Siobhan