[dpdk-dev] [PATCH] app/testpmd: fix dead code

[Jingjing Wu]

Coverity issue (CID 119254): Control flow issues (DEADCODE).

Fixes: 1a572499beb6 ("app/testpmd: setup DCB forwarding based on traffic class")
Signed-off-by: Jingjing Wu 
---
 app/test-pmd/config.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index e2030b0..7088f6f 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1251,10 +1251,7 @@ dcb_fwd_config_setup(void)
/* reinitialize forwarding streams */
init_fwd_streams();
sm_id = 0;
-   if ((rxp & 0x1) == 0)
-   txp = (portid_t) (rxp + 1);
-   else
-   txp = (portid_t) (rxp - 1);
+   txp = 1;
/* get the dcb info on the first RX and TX ports */
(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[rxp], &rxp_dcb_info);
(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[txp], &txp_dcb_info);
-- 
2.4.0

[dpdk-dev] [PATCH] i40e: fix set max frame size to default

[Jingjing Wu]

In FreeBsd driver, the max frame size is changed to MTU, but not
keep the default value defined in DataSheet. When DPDK runs on that
NIC, the configured value is not expected.
This patch sets the max frame size to default when initialization.

Fixes: 4861cde46116 ("i40e: new poll mode driver")

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/i40e_ethdev.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 22b240c..bf6220d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -919,6 +919,11 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 */
i40e_add_tx_flow_control_drop_filter(pf);

+   /* Set the max frame size to 0x2600 by default,
+* in case other drivers changed the default value.
+*/
+   i40e_aq_set_mac_config(hw, I40E_FRAME_SIZE_MAX, TRUE, 0, NULL);
+
/* initialize mirror rule list */
TAILQ_INIT(&pf->mirror_list);

-- 
2.4.0

[dpdk-dev] releases scheduling

[Vincent JARDIN]

On 15/12/2015 22:15, Wiles, Keith wrote:
> I see the YY.MM.PP (PP is patch number) as the simplest way to keep track of 
> when a release was done.

+1

I like it.

[dpdk-dev] [dpdk-announce] DPDK 2.2.0 released

[Thomas Monjalon]

? l'approche des f?tes de No?l, la communaut? DPDK est fi?re d'annnoncer
qu'une nouvelle version est disponible:
http://dpdk.org/browse/dpdk/tag/?id=v2.2.0

The statistics are - again - impressive:
797 patches from 100 authors
709 files changed, 84203 insertions(+), 13473 deletions(-)

The participation is increasing a lot with 70 new contributors
(including authors, reviewers and testers):
Thanks to Aaron Conole, Amruta Zende, Andriy Berestovskyy, Chas Williams,
Christian Ehrhardt, Christoph Gysin, Claire Murphy, David Hunt, Des O Dea,
Dex Chen, Don Provan, Fan Zhang, Ferruh Yigit, Fiona Trahe, Flavio Leitner,
Francesco Santoro, Guo Xin, Harry van Haaren, Ian Betts, Igor Ryzhov,
Jerin Jacob, Jerome Jutteau, Jesper Wramberg, Jianbo Liu, Jianfeng Tan,
John Daley, John Griffin, John J Browne, Jon DeVree, Julien Meunier,
Lee Roberts, Marcel Apfelbaum, Marcin Kerlin, Mario Carrillo, Mark Smith,
Matej Vido, Mauricio Vasquez B, Michael S. Tsirkin, Mike Sowka, Ming Zhao,
Mukesh Dua, Na Na, Nathan Law, Nicolas Harnois, Pavel Krauz,
Piotr Bartosiewicz, Rasesh Mody, Raslsn Darawsheh, Remy Horton, Rich Lane,
Robin Jarry, Roger Melton, Rolf Neugebauer, Shesha Sreenivasamurthy,
Stephen Hurd, Thiago Martins, Tim Shearer, Tiwei Bie, Victor Kaplansky,
Vlastimil Kosar, Weichun Chen, Wen-Chi Yang, Xiaobo Chi, Xiao Wang, Xutao Sun,
Yaacov Hazan, Yongjie Gu, Yuanhan Liu, Yulong Pei, Yu Nemo Wenbin.

These new contributors are associated with these domain names:
6wind.com, akamai.com, alibaba-inc.com, anritsu.com, arccn.ru, asaltech.com,
atendesoftware.pl, bigswitch.com, bivio.net, broadcom.com, brocade.com,
canonical.com, caviumnetworks.com, cisco.com, ctbri.com.cn, ezchip.com, 
gmail.com, hpe.com, intel.com, linaro.org, luminatewireless.com,
mail.ustc.edu.cn, mellanox.com, netronome.com, nokia.com, outscale.com, 
overturenetworks.com, qlogic.com, redhat.com, rehivetech.com,
ruckuswireless.com, semihalf.com, studenti.polito.it, vault24.org.

Changelog (main enhancements since 2.1.0):
* ARM v7
* ARM v8
* ring freeing
* keep alive monitoring
* more sched subports
* extended statistics
* get queue information
* precision time protocol with Intel devices
* TSO with igb, fm10k
* Rx interrupt with e1000 and i40e
* vector optimizations for i40e, fm10k and virtio
* vhost multi-queue
* Mellanox mlx5 networking driver
* Netronome nfp networking driver
* szedata2 100G networking driver
* crypto API (experimental)
* Intel AES-NI multi-buffer crypto driver
* Intel QuickAssist crypto driver
* option -d works with directories
* more in packet framework
* ethtool example
* l-thread example
* standard make install

More details in the release notes:
http://dpdk.org/doc/guides/rel_notes/release_2_2.html

The new features for the 2.3 cycle must be submitted before February.
The features properly reviewed and approved before March 3rd will be part
of the next release.

May the force be with DPDK!

[dpdk-dev] problem vhost-user sockets

[Yuanhan Liu]

On Tue, Dec 15, 2015 at 03:41:23PM +0300, Pavel Fedin wrote:
>  Hello!
> 
>  I have a question regarding vhostuser. If we cannot bind to a socket, why do 
> we simply fail with error instead of just unlink()ing
> the path before binding?

I'm thinking you can't simply unlink a file given by a user inside
a libraray unconditionaly. Say, what if a user gives a wrong socket
path?

> 
>  This causes a very annoying problem with ovs. After ovs is stopped (i use 
> supplied system integration), these sockets are not
> removed. Looks like ovs just exits without correct cleanup. This effectively 
> causes my vhostuser interfaces to go down until i clean
> them up manually. And i have to do it after every ovs restart, every system 
> reboot, etc. It is very annoying.
>  I understand that the app should really do correct cleanup upon exit. But 
> what if it abnormally crashes because of some reason
> (bug, attack, etc)? Shouldn't it be able to automatically recover?

I normally write a short script to handle it automatically.

--yliu

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Yuanhan Liu]

On Tue, Dec 15, 2015 at 04:48:12PM +0300, Pavel Fedin wrote:
>  Hello!
> 
> > >  Wrong. I tried to unconditionally enforce it in qemu (my guest does 
> > > support it), and the
> > link stopped working at all. I don't understand why.
> > 
> > I'm wondering how did you do that? Why do you need enforece it in QEMU?
> > Isn't it already supported so far?
> 
>  I mean - qemu first asks vhost-user server (ovs/DPDK in our case) about 
> capabilities, then negotiates them with the guest. And DPDK
> doesn't report VIRTIO_NET_F_GUEST_ANNOUNCE, so i just ORed this flag in qemu 
> before the negotiation with guest (because indeed my
> logic says that the host should not do anything special about it). So the 
> overall effect is the same as in your patch

I see.

> 
> > diff --git a/lib/librte_vhost/virtio-net.c
> > b/lib/librte_vhost/virtio-net.c
> > index 03044f6..0ba5045 100644
> > --- a/lib/librte_vhost/virtio-net.c
> > +++ b/lib/librte_vhost/virtio-net.c
> > @@ -74,6 +74,7 @@ static struct virtio_net_config_ll *ll_root;
> >  #define VHOST_SUPPORTED_FEATURES ((1ULL << VIRTIO_NET_F_MRG_RXBUF) | \
> > (1ULL << VIRTIO_NET_F_CTRL_VQ) | \
> > (1ULL << VIRTIO_NET_F_CTRL_RX) | \
> > +   (1ULL << VIRTIO_NET_F_GUEST_ANNOUNCE) | \
> > (VHOST_SUPPORTS_MQ)| \
> > (1ULL << VIRTIO_F_VERSION_1)   | \
> > (1ULL << VHOST_F_LOG_ALL)  | \
> 
>  But i was somehow wrong and this causes the whole thing to stop working 
> instead. Even after just booting up the network doesn't
> work and PINGs do not pass.

No idea. Maybe you have changed some other configures (such as of ovs)
without notice? Or, the ovs bridge interface resets?

BTW, would you please try my v1 patch set with above diff applied to
see if the ping loss is still there. You might also want to run tcpdump
with the dest host ovs bridge, to see if GARP is actually sent.

> 
> > However, I found the GARP is not sent out at all, due to an error
> > I met and reported before:
> > 
> > KVM: injection failed, MSI lost (Operation not permitted)

I was thinking that may be caused by the difference of my two hosts (a
desktop and a server). I will try to find two similar hosts tomorrow
to do more tests. Besides that, it'd be great if you could do a more
test with above diff applied.

--yliu
> 
>  Interesting, i don't have this problem here. Some bug in your 
> kernel/hardware?
> 
> > One thing worth noting is that it happened only when I did live migration
> > on two different hosts (the two hosts happened to be using a same old
> > kernel: v3.11.10).  It works pretty well on same host. So, seems like
> > a KVM bug then?
> 
>  3.18.9 here and no this problem.
> 
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
> 

[dpdk-dev] VFIO no-iommu

[Alex Williamson]

On Wed, 2015-12-16 at 04:04 +, Ferruh Yigit wrote:
> On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote:
> > On Tue, 2015-12-15 at 13:43 +, O'Driscoll, Tim wrote:
> > > > -Original Message-
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex
> > > > Williamson
> > > > Sent: Friday, December 11, 2015 11:03 PM
> > > > To: Vincent JARDIN; dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] VFIO no-iommu
> > > > 
> > > > On Fri, 2015-12-11 at 23:12 +0100, Vincent JARDIN wrote:
> > > > > Thanks Thomas for putting back this topic.
> > > > > 
> > > > > Alex,
> > > > > 
> > > > > I'd like to hear more about the impacts of "unsupported":
> > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g
> > > > > it/c
> > > > > ommi
> > > > > t/?id=033291eccbdb1b70ffc02641edae19ac825dc75d
> > > > > ???Use of this mode, specifically binding a device without a
> > > > > native
> > > > > ???IOMMU group to a VFIO bus driver will taint the kernel and
> > > > > should
> > > > > ???therefore not be considered supported.
> > > > > 
> > > > > It means that we get ride of uio; so it is a nice code
> > > > > cleanup:
> > > > > but
> > > > > why
> > > > > would VFIO/NO IOMMU be better if the bottomline is
> > > > > "unsupported"?
> > > > 
> > > > How supportable do you think the uio method is? ?Fundamentally
> > > > we
> > > > have
> > > > a userspace driver doing unrestricted DMA; it can access and
> > > > modify
> > > > any
> > > > memory in the system. ?This is the reason uio won't provide a
> > > > mechanism
> > > > to enable MSI and if you ask the uio maintainer, they don't
> > > > support
> > > > DMA
> > > > at all, it's only intended as a programmed IO interface to the
> > > > device.
> > > > ?Unless we can sandbox a user owned device within an IOMMU
> > > > protected
> > > > container, it's not supportable. ?The VFIO no-iommu mode can
> > > > simply
> > > > provide you that unsupported mode more easily since it
> > > > leverages
> > > > code
> > > > from the supported mode, which is IOMMU protected. ?Thanks,
> > > 
> > > Thanks for clarifying.
> > > 
> > > This does seem like it would be useful for DPDK. We're doing some
> > > further investigation to see if it works out of the box with DPDK
> > > or
> > > if we need to make any changes to support it.
> > 
> > The iommu model is different, there's no type1 interface available
> > when
> > using this mode since we have no ability to provide translation.
> > ?The
> > no-iommu iommu model really does nothing, which is a possible issue
> > for
> > userspace. ?Is it sufficient? ?We stopped short of creating a page
> > pinning interface through the no-iommu model because it requires
> > code
> > and adding piles of new code for an interface we claim is
> > unsupported
> > doesn't make a lot of sense. ?The device interface should be
> > identical
> > to existing vfio support.
> > 
> > > Thomas highlighted that your original commit for this had been
> > > reverted. What specifically would you need from us in order to
> > > re-
> > > submit the VFIO No-IOMMU support?
> > 
> > No API changes should ever go into the kernel without being
> > validated
> > by a user. ?Without that we're risking that the kernel interface is
> > broken and we're stuck supporting it. ?In this case I tried to make
> > sure we had a working user before it went it, gambled that it was
> > close
> > enough to put in anyway, then paid the price when development went
> > silent on the user side. ?To get it back in, I'm going to need a
> > working use first. ?You can re-apply 033291eccbdb or re-
> > revert?ae5515d66362 for development of that. ?I need to see that it
> > works and that there's some consensus from the dpdk community that
> > it's
> > a worthwhile path forward for cases without an iommu. ?There's no
> > point
> > in merging it if it only becomes a userspace proof of concept.
> > ?Thanks,
> > 
> I tested the DPDK (HEAD of master) with the patch, with help of
> Anatoly,
> and DPDK works in no-iommu environment with a little modification.
> 
> Basically the only modification is adapt new group naming (noiommu-$) 
> and

Sorry, forgot to mention that one. ?The intention with the modified
group name is that I want to be very certain that a user intending to
only support properly iommu isolated devices doesn't accidentally need
to deal with these no-iommu mode devices.

> disable dma mapping (VFIO_IOMMU_MAP_DMA)
> 
> Also I need to disable VFIO_CHECK_EXTENSION ioctl, because in vfio
> module,
> container->noiommu is not set before doing a
> vfio_group_set_container()
> and vfio_for_each_iommu_driver selects wrong driver.

Running CHECK_EXTENSION on a container without the group attached is
only going to tell you what extensions vfio is capable of, not
necessarily what extensions are available to you with that group. ?Is
this just a general dpdk-vfio ordering bug?

> What I test is bind two different type of NICs into VFIO driver, and
> use
> testpmd to c

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Yuanhan Liu]

On Tue, Dec 15, 2015 at 03:24:48PM +0300, Pavel Fedin wrote:
>  Hello!
> 
> > After a migration, to avoid network outage, the guest must announce its new 
> > location to the L2 layer, typically with a GARP. Otherwise requests sent to
> > the guest arrive to the old host until a ARP request is sent (after 30 
> > seconds) or the guest sends some data.
> > QEMU implementation of self announce after a migration with a vhost backend 
> > is the following:
> > - If the VIRTIO_GUEST_ANNOUNCE feature has been negotiated the guest sends 
> > automatically a GARP.
> > - Else if the vhost backend implements VHOST_USER_SEND_RARP this request is 
> > sent to the vhost backend. When this message is received the vhost backend
> > must act as it receives a RARP from the guest (purpose of this RARP is to 
> > update switches' MAC->port maaping as a GARP). This RARP is a false one,
> > created by the vhost backend,
> > - Else nothing is done and we have a network outage until a ARP is sent or 
> > the guest sends some data.
> 
>  But what is qemu_announce_self() then? It's just unconditionally triggered 
> after migration, but indeed sends some strange thing.
> 
> > VIRTIO_GUEST_ANNOUNCE feature is negotiated if:
> >  - the vhost backend announces the support of this feature. Maybe QEMU can 
> > be updated to support unconditionnaly this feature
> 
>  Wrong. I tried to unconditionally enforce it in qemu (my guest does support 
> it), and the link stopped working at all. I don't understand why.

I'm wondering how did you do that? Why do you need enforece it in QEMU?
Isn't it already supported so far?

Actually, what's we need to do is to add such feature bit in vhost
library, to claim we support it so that the the guest will send a 
gratuitous ARP when migration is done (check virtio_net_load()).


diff --git a/lib/librte_vhost/virtio-net.c
b/lib/librte_vhost/virtio-net.c
index 03044f6..0ba5045 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -74,6 +74,7 @@ static struct virtio_net_config_ll *ll_root;
 #define VHOST_SUPPORTED_FEATURES ((1ULL << VIRTIO_NET_F_MRG_RXBUF) | \
(1ULL << VIRTIO_NET_F_CTRL_VQ) | \
(1ULL << VIRTIO_NET_F_CTRL_RX) | \
+   (1ULL << VIRTIO_NET_F_GUEST_ANNOUNCE) | \
(VHOST_SUPPORTS_MQ)| \
(1ULL << VIRTIO_F_VERSION_1)   | \
(1ULL << VHOST_F_LOG_ALL)  | \

However, I found the GARP is not sent out at all, due to an error
I met and reported before:

KVM: injection failed, MSI lost (Operation not permitted)

Which happened at the time QEMU is about to send the interrupt to the 
guest for announce event. However, it failed, hence no GARP was received.

One thing worth noting is that it happened only when I did live migration
on two different hosts (the two hosts happened to be using a same old 
kernel: v3.11.10).  It works pretty well on same host. So, seems like
a KVM bug then?

--yliu

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Yuanhan Liu]

On Tue, Dec 15, 2015 at 12:47:47PM +0100, Thibaut Collet wrote:
> On Tue, Dec 15, 2015 at 12:43 PM, Thibaut Collet 
> wrote:
> 
> >
> >
> > On Tue, Dec 15, 2015 at 11:05 AM, Peter Xu  wrote:
> >
> >> On Tue, Dec 15, 2015 at 11:45:56AM +0300, Pavel Fedin wrote:
> >> >  To tell the truth, i don't know. I am also learning qemu internals on
> >> the fly. Indeed, i see that it should announce itself. But
> >> > this brings up a question: why do we need special announce procedure in
> >> vhost-user then?
> >>
> >> I have the same question. Here is my guess...
> >>
> >> In customized networks, maybe people are not using ARP at all? When
> >> we use DPDK, we directly pass through the network logic inside
> >> kernel itself. So logically all the network protocols could be
> >> customized by the user of it. In the customized network, maybe there
> >> is some other protocol (rather than RARP) that would do the same
> >> thing as what ARP/RARP does. So, this SEND_RARP request could give
> >> the vhost-user backend a chance to format its own announce packet
> >> and broadcast (in the SEND_RARP request, the guest's mac address
> >> will be appended).
> >>
> >> CCing Victor to better know the truth...
> >>
> >> Peter
> >>
> >

Hey Thibaut,

First of all, thanks a lot for your lengthy explanation.

> > Hi,
> >
> > After a migration, to avoid network outage, the guest must announce its
> > new location to the L2 layer, typically with a GARP. Otherwise requests
> > sent to the guest arrive to the old host until a ARP request is sent (after
> > 30 seconds) or the guest sends some data.
> >
> > QEMU implementation of self announce after a migration with a vhost
> > backend is the following:
> >  - If the VIRTIO_GUEST_ANNOUNCE feature has been negotiated the guest
> > sends automatically a GARP.

I'm kind of clear how VIRTIO_GUEST_ANNOUNCE works so far, except that I
met a bug, which I will describe in another email.

> >  - Else if the vhost backend implements VHOST_USER_SEND_RARP this request
> > is sent to the vhost backend. When this message is received the vhost
> > backend must act as it receives a RARP from the guest (purpose of this RARP

Can you be more specific about this? Say, what kind of acts the vhost
backend should do exactly?

> > is to update switches' MAC->port maaping as a GARP).

Isn't it vhost library is not aware of swtich at all? How could we
update switches's MAC-port mapping inside vhost library?

> This RARP is a false
> > one, created by the vhost backend,

I'm a bit confused now. You were just saying "vhost backend must act
as it __recevives__ a RARP from the guest", and you are now saying
"the RARP is a false one __created__ by the vhost backend".

Thanks.

--yliu

[dpdk-dev] releases scheduling

[Wiles, Keith]

On 12/15/15, 1:15 PM, "dev on behalf of Dave Neary"  wrote:

>Hi,
>
>You could just bump the major version for the first release of the new
>year - in this case, we would make 2.6 be 3.0. It achieves the same
>objective without having a big discontinuity in the release numbers.

I see the YY.MM.PP (PP is patch number) as the simplest way to keep track of 
when a release was done. Trying to remember when 3.4 or even 1.8 was released 
is difficult with a pure version number format without a good memory or cheat 
sheet. The YY.MM give us a great way to tell when a release was made and we can 
still have patch releases if required. Moving to a YY.MM format is better then 
moving to 3.0 as it still does not let me know when a release was done. If we 
pick say 16.03 as the LTS then every X years say 2 years (18.03 LTS) we then 
know which version is the LTS version. The nice part about 2 or 4 year LTS 
releases we know that a even number year would have a LTS release. I am open to 
whatever number of years people believe is the best.
>
>Thanks,
>Dave.
>
>
>
>On 12/15/2015 08:37 AM, O'Driscoll, Tim wrote:
>> 
>>> -Original Message-
>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>>> Sent: Sunday, December 13, 2015 7:23 PM
>>> To: dev at dpdk.org
>>> Subject: [dpdk-dev] releases scheduling
>>>
>>> Hi all,
>>>
>>> We need to define the deadlines for the next releases.
>>> During 2015, we were doing a release every 4 months.
>>> If we keep the same pace, the next releases would be:
>>> 2.3: end of March
>>> 2.4: end of July
>>> 2.5: end of November
>>>
>>> However, things move fast and it may be a bit long to wait 4 months for
>>> a feature. That's why I suggest to progressively shorten release terms:
>>> 2.3: end of March
>>> 2.4: mid July
>>> 2.5: end of October
>>> and continue with a release every 3 months:
>>> 2.6: end of January
>>> 2.7: end of April
>>> 2.8: end of July
>>> This planning would preserve some of the major holiday periods
>>> (February, May, August, December).
>>>
>>> The first period, for the first submission of a feature, was 2 months
>>> long.
>>> Then we had 2 other months to discuss, merge and fix.
>>> We should shorten only the first period.
>>>
>>> Anyway, the next deadlines should be unchanged:
>>> - January 31: end of first submission phase
>>> - March 31: release 2.3
>>>
>>> Opinions are welcome.
>> 
>> I think moving to quarterly releases is a good idea. Your proposal to do 
>> this in a gradual way, so that we don't change the 2.3 dates, also makes 
>> sense.
>> 
>> Should we consider changing the release numbering at the same time? It's 
>> difficult to keep track of when each 2.x release is due, and we don't have 
>> any criteria in place for moving to 3.x in future. Many people like the 
>> Ubuntu numbering scheme of Year.Month. Should we consider adopting that 
>> convention? If we move in future to a model where we have long-term support 
>> releases (something that was touched on in Dublin), then we could append an 
>> LTS designation to the release number.
>> 
>> 
>> Tim
>> 
>
>-- 
>Dave Neary - NFV/SDN Community Strategy
>Open Source and Standards, Red Hat - http://community.redhat.com
>Ph: +1-978-399-2182 / Cell: +1-978-799-3338
>


Regards,
Keith

[dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support

[Rahul Lakkireddy]

Current filtering support will be enhanced to accommodate support
for Chelsio T5 hardware filtering support.

Signed-off-by: Rahul Lakkireddy 
Signed-off-by: Kumar Sanghvi 
---
 doc/guides/rel_notes/deprecation.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index f8a41dd..15e766d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -41,3 +41,11 @@ Deprecation Notices
   commands (such as RETA update in testpmd).  This should impact
   CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
   It should be integrated in release 2.3.
+
+* ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow to
+  include more fields to be matched against. The release 2.2 does not
+  contain these ABI changes, but release 2.3 will.
+
+* ABI changes are planned for adding four new flow types. This impacts
+  RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
+  but release 2.3 will.
-- 
2.5.3

[dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support

[Rahul Lakkireddy]

Hi Thomas,

On Tuesday, December 12/15/15, 2015 at 00:55:20 -0800, Thomas Monjalon wrote:
> 2015-12-15 14:10, Rahul Lakkireddy:
> > Hi Thomas,
> > 
> > I am preparing a v2 of this series where I will be accomodating some
> > more fields to be considered for filtering. However, if the overall
> > approach seems ok to everyone then, should I submit a separate patch
> > for this ABI change announcement ?
> 
> Yes, if this announce is not enough:
>   http://dpdk.org/browse/dpdk/commit/?id=648e6b3815a35
> 

Apart from rte_eth_fdir_flow ABI change mentioned in above link, new
fields will be added to rte_eth_ipv4_flow and rte_eth_ipv6_flow,
which break their ABI.

Also, 4 new flow types will be added, which increases RTE_ETH_FLOW_MAX
from 18 to 22 and breaks the ABI.

Should I send a separate ABI change announce patch for each of them?

Thanks,
Rahul

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Pavel Fedin]

 Hello!

> After a migration, to avoid netwotk outage, all interfaces of the guest must 
> send a packet to update switches mapping (ideally a GARP).
> As some interfaces do not do it QEMU does it in behalf of the guest by 
> sending a RARP (his RARP is not forged by the guest but by QEMU). This is the
> qemu_self_announce purpose that "spoofs" a RARP to all backend of guest 
> ethernet interfaces. For vhost-user backend, QEMU can not do it directly

 Aha, see it now. qemu_announce_self() uses qemu_foreach_nic(), which actually 
iterates only over NET_CLIENT_OPTIONS_KIND_NIC interfaces. I expect these are 
fully emulated hardware controllers. virtio uses another type (see enum 
NetClientOptionsKind).
 So, we can happily ignore qemu_announce_self(), it does not do anything for 
us. Thanks for pointing it out.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

[dpdk-dev] [PATCH] app/testpmd: fix dead code

[Thomas Monjalon]

> > Coverity issue (CID 119254): Control flow issues (DEADCODE).
> > 
> > Fixes: 1a572499beb6 ("app/testpmd: setup DCB forwarding based on traffic
> > class")
> > Signed-off-by: Jingjing Wu 
> 
> Acked-by: John McNamara 

Applied, thanks

[dpdk-dev] [PATCH] i40e: fix unintended sign extension

[Thomas Monjalon]

 > Coverity issue reported like
> > CID 119268 (#1 of 1): Unintended sign extension
> > (SIGN_EXTENSION)sign_extension: Suspicious implicit sign extension:
> > vsi_id with type unsigned short (16 bits, unsigned) is promoted in vsi_id
> > << 23 to type int (32 bits, signed), then sign-extended to type unsigned
> > long (64 bits, unsigned). If vsi_id << 23 is greater than 0x7FFF, the
> > upper bits of the result will all be 1.
> > 
> > Fixes: 88ebc2b7f976 ("i40e: extend flow director to support VF")
> > Signed-off-by: Jingjing Wu 
> 
> Acked-by: John McNamara 

Applied, thanks

[dpdk-dev] [PATCH] ixgbe: restore imissed stat counter

[Thomas Monjalon]

2015-12-15 16:41, Van Haaren, Harry:
> > From: Robin Jarry [mailto:robin.jarry at 6wind.com]
> > Subject: [PATCH] ixgbe: restore imissed stat counter
> > 
> > This counter was left unmodified. Restore it in ixgbe_dev_stats_get.
> > 
> > The ierrors counter still includes imissed for ixgbe. This behaviour is
> > not consistent amongst all drivers. Another patch may be needed to unify
> > the meaning of the ierrors counter.
> > 
> > Fixes: 5e50ad1c1b63 ("ixgbe: add specific stats")
> > 
> > Signed-off-by: Robin Jarry 
> 
> There is work to be done to allow easier distinction between
> drops due to the host, and errors due to bad packets.
> 
> Until that work is done, write the dropped packet count to imissed, so:
> 
> Acked-by: Harry van Haaren 

Applied, thanks

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Peter Xu]

On Tue, Dec 15, 2015 at 11:45:56AM +0300, Pavel Fedin wrote:
>  To tell the truth, i don't know. I am also learning qemu internals on the 
> fly. Indeed, i see that it should announce itself. But
> this brings up a question: why do we need special announce procedure in 
> vhost-user then?

I have the same question. Here is my guess...

In customized networks, maybe people are not using ARP at all? When
we use DPDK, we directly pass through the network logic inside
kernel itself. So logically all the network protocols could be
customized by the user of it. In the customized network, maybe there
is some other protocol (rather than RARP) that would do the same
thing as what ARP/RARP does. So, this SEND_RARP request could give
the vhost-user backend a chance to format its own announce packet
and broadcast (in the SEND_RARP request, the guest's mac address
will be appended).

CCing Victor to better know the truth...

Peter

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Pavel Fedin]

 Hello!

> No idea. Maybe you have changed some other configures (such as of ovs)
> without notice? Or, the ovs bridge interface resets?

 I don't touch the ovs at all. Just shut down the guest, rebuild the qemu, 
reinstall it, run the guest.

> 
> BTW, would you please try my v1 patch set with above diff applied to
> see if the ping loss is still there. You might also want to run tcpdump
> with the dest host ovs bridge, to see if GARP is actually sent.

 Retested with wireshark running on the host. I used my qemu patch instead, but 
it should not matter at all:
--- cut ---
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 1b6c5ac..5ca2987 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -480,7 +480,12 @@ static int vhost_user_get_u64(struct vhost_dev *dev, int 
request, uint64_t *u64)

 static int vhost_user_get_features(struct vhost_dev *dev, uint64_t *features)
 {
-return vhost_user_get_u64(dev, VHOST_USER_GET_FEATURES, features);
+int ret = vhost_user_get_u64(dev, VHOST_USER_GET_FEATURES, features);
+
+if (!ret) {
+virtio_add_feature(features, VIRTIO_NET_F_GUEST_ANNOUNCE);
+}
+return ret;
 }

 static int vhost_user_set_owner(struct vhost_dev *dev)
--- cut ---

 So, here are both wireshark captures on the host side:

1. Without the patch

root at nfv_test_x86_64 / # tshark -i ovs-br0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ovs-br0'
  1   0.00   :: -> ff02::16 ICMPv6 90 Multicast Listener Report 
Message v2
  2   0.003304 RealtekU_3b:83:1a -> BroadcastARP 42 Gratuitous ARP for 
192.168.6.2 (Reply)
  3   0.669957   :: -> ff02::16 ICMPv6 90 Multicast Listener Report 
Message v2
  4   0.858957   :: -> ff02::1:ff3b:831a ICMPv6 78 Neighbor 
Solicitation for fe80::5054:ff:fe3b:831a
  5   1.858968 fe80::5054:ff:fe3b:831a -> ff02::16 ICMPv6 90 Multicast 
Listener Report Message v2
  6   2.300948 fe80::5054:ff:fe3b:831a -> ff02::16 ICMPv6 90 Multicast 
Listener Report Message v2
  7   2.527088 fe80::5054:ff:fe3b:831a -> ff02::2  ICMPv6 62 Router 
Solicitation
  8   2.527800 RealtekU_3b:83:1a -> BroadcastARP 42 Gratuitous ARP for 
192.168.6.2 (Request)
  9   6.526814 fe80::5054:ff:fe3b:831a -> ff02::2  ICMPv6 62 Router 
Solicitation
 10  10.526993 fe80::5054:ff:fe3b:831a -> ff02::2  ICMPv6 62 Router 
Solicitation
 11  15.984632 RealtekU_3b:83:1a -> BroadcastARP 42 Who has 192.168.6.1?  
Tell 192.168.6.2
 12  15.984643 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at 
be:e1:71:c1:47:4d
 13  15.984772  192.168.6.2 -> 192.168.6.1  ICMP 98 Echo (ping) request  
id=0x0477, seq=1/256, ttl=64
 14  15.984798  192.168.6.1 -> 192.168.6.2  ICMP 98 Echo (ping) reply
id=0x0477, seq=1/256, ttl=64 (request in 13)
 15  16.984970  192.168.6.2 -> 192.168.6.1  ICMP 98 Echo (ping) request  
id=0x0477, seq=2/512, ttl=64
 16  16.984991  192.168.6.1 -> 192.168.6.2  ICMP 98 Echo (ping) reply
id=0x0477, seq=2/512, ttl=64 (request in 15)
 17  17.984956  192.168.6.2 -> 192.168.6.1  ICMP 98 Echo (ping) request  
id=0x0477, seq=3/768, ttl=64
 18  17.984975  192.168.6.1 -> 192.168.6.2  ICMP 98 Echo (ping) reply
id=0x0477, seq=3/768, ttl=64 (request in 17)
 19  20.994535 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 Who has 
192.168.6.2?  Tell 192.168.6.1
 20  20.994637 RealtekU_3b:83:1a -> be:e1:71:c1:47:4d ARP 42 192.168.6.2 is at 
52:54:00:3b:83:1a
^C20 packets captured

2. With the patch

root at nfv_test_x86_64 / # tshark -i ovs-br0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ovs-br0'
  1   0.00   :: -> ff02::16 ICMPv6 90 Multicast Listener Report 
Message v2
  2   0.000969 RealtekU_3b:83:1a -> BroadcastARP 42 Gratuitous ARP for 
192.168.6.2 (Reply)
  3   0.156966   :: -> ff02::1:ff3b:831a ICMPv6 78 Neighbor 
Solicitation for fe80::5054:ff:fe3b:831a
  4   0.536948   :: -> ff02::16 ICMPv6 90 Multicast Listener Report 
Message v2
  5   1.156968 fe80::5054:ff:fe3b:831a -> ff02::16 ICMPv6 90 Multicast 
Listener Report Message v2
  6   1.312708 fe80::5054:ff:fe3b:831a -> ff02::2  ICMPv6 62 Router 
Solicitation
  7   1.629960 fe80::5054:ff:fe3b:831a -> ff02::16 ICMPv6 90 Multicast 
Listener Report Message v2
  8   2.314713 RealtekU_3b:83:1a -> BroadcastARP 42 Gratuitous ARP for 
192.168.6.2 (Request)
  9   5.31 fe80::5054:ff:fe3b:831a -> ff02::2  ICMPv6 62 Router 
Solicitation
 10   9.315486 fe80::5054:ff:fe3b:831a -> ff02::2  ICMPv6 62 Router 
Solicitation
 11  21.536450 RealtekU_3b:83:1a -> BroadcastARP 42 Who has 192.168.6.1?  
Tell 192.168.6.2
 12  21.536461 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at 
be:e1:71:c1:47:4d
 13  22.538937 RealtekU_3b:83:1a -> BroadcastARP 42 Who has 192.168.6.1?  
Tell 192.168.6.2
 14  22.538943 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 192.168.6.1 is at 
be:e1:71:c1:47:4d
 15  23.54

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Peter Xu]

On Tue, Dec 15, 2015 at 04:23:24PM +0800, Yuanhan Liu wrote:
> On Mon, Dec 14, 2015 at 11:58:42AM +0800, Peter Xu wrote:
> > If ping to guest from outside, when the migration finishes on the
> > target side of qemu, qemu_self_announce() will be called.
> 
> It's supposed to see some ARP requests if I run tcpdump against
> with the ovs bridge, right? However, in fact, I saw nothing from
> tcpdump on the target host when the migration is done.
> 
> I mean I do find that qemu_annouce_self composes an ARP
> broadcoast request, but it seems that I didn't catch it on
> the target host.
> 
> Something wrong, or someting I missed?

AFAIK, it should be RARP rather than ARP request. However, sorry
that I do not know the reason for its lossing either.

Btw, I did a very basic live migration using v1 patchset locally
today (one host, two QEMU instances attach to the same vhost-user
socket), it's working too on my host. :)

Thanks.
Peter

> 
>   --yliu
> 
> > Although
> > we might see a warning like "Vhost user backend fails to broadcast
> > fake RARP" (notify is done by hacking vhost_user_receive(), even if
> > notify fails, things will still move on), QEMU should still send a
> > RARP onto the link.
> > 
> > Not sure whether I missed anything.
> > 
> > Thanks.
> > Peter

[dpdk-dev] [PATCH] i40e: fix set max frame size to default

[Thomas Monjalon]

> In FreeBsd driver, the max frame size is changed to MTU, but not keep the 
> default value defined in DataSheet. When DPDK runs on that NIC, the 
> configured value is not expected.
> This patch sets the max frame size to default when initialization.
> 
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
> 
> Signed-off-by: Jingjing Wu 
> Acked-by: Helin Zhang 

Applied, thanks

[dpdk-dev] problem vhost-user sockets

[Pavel Fedin]

 Hello!

> I'm thinking you can't simply unlink a file given by a user inside
> a libraray unconditionaly. Say, what if a user gives a wrong socket
> path?

 Well... We can improve the security by checking that:

a) The file exists and it's a socket.
b) Nobody is listening on it.

> I normally write a short script to handle it automatically.

 I know, you can always hack up some kludges, just IMHO it's not 
production-grade solution. What if you are cloud administrator, and
you have 1000 users, each of them using 100 vhost-user interfaces? List all of 
them in some script? Too huge job, i would say.
 And without it the thing just appears to be too fragile, requiring manual 
maintenance after a single stupid failure.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

[dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration

[Thomas Monjalon]

> Replace "entries" by "queues", it clarifies the case.
> 
> Fixes: bd3cea78abd8 ("doc: announce ABI change for RETA configuration")
> 
> Signed-off-by: Nelio Laranjeiro 
> Acked-by: Helin Zhang 

Applied, thanks

[dpdk-dev] [PATCH] ixgbe: restore imissed stat counter

[Robin Jarry]

This counter was left unmodified. Restore it in ixgbe_dev_stats_get.

The ierrors counter still includes imissed for ixgbe. This behaviour is
not consistent amongst all drivers. Another patch may be needed to unify
the meaning of the ierrors counter.

Fixes: 5e50ad1c1b63 ("ixgbe: add specific stats")

Signed-off-by: Robin Jarry 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 1b6cd8efe815..4c4c6dfb1622 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2546,6 +2546,7 @@ ixgbe_dev_stats_get(struct rte_eth_dev *dev, struct 
rte_eth_stats *stats)
}

/* Rx Errors */
+   stats->imissed  = total_missed_rx;
stats->ierrors  = hw_stats->crcerrs +
  hw_stats->mspdc +
  hw_stats->rlec +
-- 
2.1.4

[dpdk-dev] [PATCH] i40e: fix unintended sign extension

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jingjing Wu
> Sent: Tuesday, December 15, 2015 4:23 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] i40e: fix unintended sign extension
> 
> Coverity issue reported like
> CID 119268 (#1 of 1): Unintended sign extension
> (SIGN_EXTENSION)sign_extension: Suspicious implicit sign extension:
> vsi_id with type unsigned short (16 bits, unsigned) is promoted in vsi_id
> << 23 to type int (32 bits, signed), then sign-extended to type unsigned
> long (64 bits, unsigned). If vsi_id << 23 is greater than 0x7FFF, the
> upper bits of the result will all be 1.
> 
> Fixes: 88ebc2b7f976 ("i40e: extend flow director to support VF")
> Signed-off-by: Jingjing Wu 

Acked-by: John McNamara 

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Yuanhan Liu]

On Tue, Dec 15, 2015 at 11:45:56AM +0300, Pavel Fedin wrote:
>  Hello!
> 
> > I mean I do find that qemu_annouce_self composes an ARP
> > broadcoast request, but it seems that I didn't catch it on
> > the target host.
> > 
> > Something wrong, or someting I missed?
> 
>  To tell the truth, i don't know. I am also learning qemu internals on the 
> fly. Indeed, i see that it should announce itself.

I was acutally asking Peter. Sorry for not making it clear and
thanks for your reply, anyway :)

> But
> this brings up a question: why do we need special announce procedure in 
> vhost-user then?

Note quite sure. I found Thibaut submitted a patch to send
VHOST_USER_SEND_RARP request after migration is done months
ago. Thibaut, would you please elaborate it a bit more what
should be done on vhost-user backend? To construct a gratuitous
ARP request and broadcast it?

>  I think you can add some debug output and see how it works in realtime. This 
> is what i normally do when i don't understand in which
> sequence things happen.

Thanks.

--yliu
> 
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
> 

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Pavel Fedin]

 Hello!

> >  Wrong. I tried to unconditionally enforce it in qemu (my guest does 
> > support it), and the
> link stopped working at all. I don't understand why.
> 
> I'm wondering how did you do that? Why do you need enforece it in QEMU?
> Isn't it already supported so far?

 I mean - qemu first asks vhost-user server (ovs/DPDK in our case) about 
capabilities, then negotiates them with the guest. And DPDK
doesn't report VIRTIO_NET_F_GUEST_ANNOUNCE, so i just ORed this flag in qemu 
before the negotiation with guest (because indeed my
logic says that the host should not do anything special about it). So the 
overall effect is the same as in your patch

> diff --git a/lib/librte_vhost/virtio-net.c
> b/lib/librte_vhost/virtio-net.c
> index 03044f6..0ba5045 100644
> --- a/lib/librte_vhost/virtio-net.c
> +++ b/lib/librte_vhost/virtio-net.c
> @@ -74,6 +74,7 @@ static struct virtio_net_config_ll *ll_root;
>  #define VHOST_SUPPORTED_FEATURES ((1ULL << VIRTIO_NET_F_MRG_RXBUF) | \
> (1ULL << VIRTIO_NET_F_CTRL_VQ) | \
> (1ULL << VIRTIO_NET_F_CTRL_RX) | \
> +   (1ULL << VIRTIO_NET_F_GUEST_ANNOUNCE) | \
> (VHOST_SUPPORTS_MQ)| \
> (1ULL << VIRTIO_F_VERSION_1)   | \
> (1ULL << VHOST_F_LOG_ALL)  | \

 But i was somehow wrong and this causes the whole thing to stop working 
instead. Even after just booting up the network doesn't
work and PINGs do not pass.

> However, I found the GARP is not sent out at all, due to an error
> I met and reported before:
> 
> KVM: injection failed, MSI lost (Operation not permitted)

 Interesting, i don't have this problem here. Some bug in your kernel/hardware?

> One thing worth noting is that it happened only when I did live migration
> on two different hosts (the two hosts happened to be using a same old
> kernel: v3.11.10).  It works pretty well on same host. So, seems like
> a KVM bug then?

 3.18.9 here and no this problem.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

[dpdk-dev] [PATCH] ixgbe: restore imissed stat counter

[Van Haaren, Harry]

> From: Robin Jarry [mailto:robin.jarry at 6wind.com]
> Subject: [PATCH] ixgbe: restore imissed stat counter
> 
> This counter was left unmodified. Restore it in ixgbe_dev_stats_get.
> 
> The ierrors counter still includes imissed for ixgbe. This behaviour is
> not consistent amongst all drivers. Another patch may be needed to unify
> the meaning of the ierrors counter.
> 
> Fixes: 5e50ad1c1b63 ("ixgbe: add specific stats")
> 
> Signed-off-by: Robin Jarry 

There is work to be done to allow easier distinction between
drops due to the host, and errors due to bad packets.

Until that work is done, write the dropped packet count to imissed, so:

Acked-by: Harry van Haaren 

[dpdk-dev] problem vhost-user sockets

[Xie, Huawei]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pavel Fedin
> Sent: Tuesday, December 15, 2015 10:21 PM
> To: 'Yuanhan Liu'
> Cc: dev at dpdk.org; 'Ilya Maximets'; 'Dyasly Sergey'
> Subject: Re: [dpdk-dev] problem vhost-user sockets
> 
>  Hello!
> 
> > I'm thinking you can't simply unlink a file given by a user inside
> > a libraray unconditionaly. Say, what if a user gives a wrong socket
> > path?
Exactly, Yuanhan. The initial thinking is it is the user's responsibility to 
provide a clean running environment and I try to avoid the dpdk app touch 
something that others might be using.
> 
>  Well... We can improve the security by checking that:
> 
> a) The file exists and it's a socket.
> b) Nobody is listening on it.
> 
> > I normally write a short script to handle it automatically.
Yes, the same to me.
> 
>  I know, you can always hack up some kludges, just IMHO it's not
> production-grade solution. What if you are cloud administrator, and
> you have 1000 users, each of them using 100 vhost-user interfaces?
> List all of them in some script? Too huge job, i would say.
>  And without it the thing just appears to be too fragile, requiring
> manual maintenance after a single stupid failure.
Pavel:
I totally understand your pain, it also brings trouble to ourselves when 
debugging, but I want to follow the best practice. Btw I don't see the trouble 
with the script here. The users should know clearly where and how to do the 
cleanup. Normally the socket files should all reside in one single directory.
For the checking you mentioned above, even the existing file has nobody 
listening on it, in theory there is no guarantee others might not use it. Of 
course, for this specific case, the chance is rare.
>From another point of view, DPDK huge re-creates rte_map files even if it 
>exists. :). 
We are open to this. Let us consider more and gather more comments. 
> 
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
> 

[dpdk-dev] releases scheduling

[Arnon Warshavsky]

+1 for Ubuntu version numbering

On Tue, Dec 15, 2015 at 3:37 PM, O'Driscoll, Tim 
wrote:

>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Sunday, December 13, 2015 7:23 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] releases scheduling
> >
> > Hi all,
> >
> > We need to define the deadlines for the next releases.
> > During 2015, we were doing a release every 4 months.
> > If we keep the same pace, the next releases would be:
> >   2.3: end of March
> >   2.4: end of July
> >   2.5: end of November
> >
> > However, things move fast and it may be a bit long to wait 4 months for
> > a feature. That's why I suggest to progressively shorten release terms:
> >   2.3: end of March
> >   2.4: mid July
> >   2.5: end of October
> > and continue with a release every 3 months:
> >   2.6: end of January
> >   2.7: end of April
> >   2.8: end of July
> > This planning would preserve some of the major holiday periods
> > (February, May, August, December).
> >
> > The first period, for the first submission of a feature, was 2 months
> > long.
> > Then we had 2 other months to discuss, merge and fix.
> > We should shorten only the first period.
> >
> > Anyway, the next deadlines should be unchanged:
> >   - January 31: end of first submission phase
> >   - March 31: release 2.3
> >
> > Opinions are welcome.
>
> I think moving to quarterly releases is a good idea. Your proposal to do
> this in a gradual way, so that we don't change the 2.3 dates, also makes
> sense.
>
> Should we consider changing the release numbering at the same time? It's
> difficult to keep track of when each 2.x release is due, and we don't have
> any criteria in place for moving to 3.x in future. Many people like the
> Ubuntu numbering scheme of Year.Month. Should we consider adopting that
> convention? If we move in future to a model where we have long-term support
> releases (something that was touched on in Dublin), then we could append an
> LTS designation to the release number.
>
>
> Tim
>



-- 

*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Yuanhan Liu]

On Mon, Dec 14, 2015 at 11:58:42AM +0800, Peter Xu wrote:
> On Fri, Dec 11, 2015 at 01:22:23PM +0300, Pavel Fedin wrote:
> >  BTW, it works, and it was my bad. openvswitch was configured incorrectly 
> > on the other side, vhost port number was different for
> > some reason, while ruleset was the same. I reconfigured it and now 
> > everything migrates correctly, except increased downtime because
> > of missing GARP (the guest misses some PINGs, then it retries ARP, which 
> > brings the link back up).
> 
> Hi,
> 
> When doing the ping, was it from the guest (to another host) or to
> the guest (from another host)?
> 
> In any case, I still could not understand why the ping loss happened
> in this test.
> 
> If ping from guest, no ARP refresh is required at all?
> 
> If ping to guest from outside, when the migration finishes on the
> target side of qemu, qemu_self_announce() will be called.

It's supposed to see some ARP requests if I run tcpdump against
with the ovs bridge, right? However, in fact, I saw nothing from
tcpdump on the target host when the migration is done.

I mean I do find that qemu_annouce_self composes an ARP
broadcoast request, but it seems that I didn't catch it on
the target host.

Something wrong, or someting I missed?

--yliu

> Although
> we might see a warning like "Vhost user backend fails to broadcast
> fake RARP" (notify is done by hacking vhost_user_receive(), even if
> notify fails, things will still move on), QEMU should still send a
> RARP onto the link.
> 
> Not sure whether I missed anything.
> 
> Thanks.
> Peter

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Thibaut Collet]

On Tue, Dec 15, 2015 at 2:18 PM, Yuanhan Liu 
wrote:

> On Tue, Dec 15, 2015 at 12:47:47PM +0100, Thibaut Collet wrote:
> > On Tue, Dec 15, 2015 at 12:43 PM, Thibaut Collet <
> thibaut.collet at 6wind.com>
> > wrote:
> >
> > >
> > >
> > > On Tue, Dec 15, 2015 at 11:05 AM, Peter Xu  wrote:
> > >
> > >> On Tue, Dec 15, 2015 at 11:45:56AM +0300, Pavel Fedin wrote:
> > >> >  To tell the truth, i don't know. I am also learning qemu internals
> on
> > >> the fly. Indeed, i see that it should announce itself. But
> > >> > this brings up a question: why do we need special announce
> procedure in
> > >> vhost-user then?
> > >>
> > >> I have the same question. Here is my guess...
> > >>
> > >> In customized networks, maybe people are not using ARP at all? When
> > >> we use DPDK, we directly pass through the network logic inside
> > >> kernel itself. So logically all the network protocols could be
> > >> customized by the user of it. In the customized network, maybe there
> > >> is some other protocol (rather than RARP) that would do the same
> > >> thing as what ARP/RARP does. So, this SEND_RARP request could give
> > >> the vhost-user backend a chance to format its own announce packet
> > >> and broadcast (in the SEND_RARP request, the guest's mac address
> > >> will be appended).
> > >>
> > >> CCing Victor to better know the truth...
> > >>
> > >> Peter
> > >>
> > >
>
> Hey Thibaut,
>
> First of all, thanks a lot for your lengthy explanation.
>
> > > Hi,
> > >
> > > After a migration, to avoid network outage, the guest must announce its
> > > new location to the L2 layer, typically with a GARP. Otherwise requests
> > > sent to the guest arrive to the old host until a ARP request is sent
> (after
> > > 30 seconds) or the guest sends some data.
> > >
> > > QEMU implementation of self announce after a migration with a vhost
> > > backend is the following:
> > >  - If the VIRTIO_GUEST_ANNOUNCE feature has been negotiated the guest
> > > sends automatically a GARP.
>
> I'm kind of clear how VIRTIO_GUEST_ANNOUNCE works so far, except that I
> met a bug, which I will describe in another email.
>
> > >  - Else if the vhost backend implements VHOST_USER_SEND_RARP this
> request
> > > is sent to the vhost backend. When this message is received the vhost
> > > backend must act as it receives a RARP from the guest (purpose of this
> RARP
>
> Can you be more specific about this? Say, what kind of acts the vhost
> backend should do exactly?
>
> > > is to update switches' MAC->port maaping as a GARP).
>
> Isn't it vhost library is not aware of swtich at all? How could we
> update switches's MAC-port mapping inside vhost library?
>
> > This RARP is a false
> > > one, created by the vhost backend,
>
> I'm a bit confused now. You were just saying "vhost backend must act
> as it __recevives__ a RARP from the guest", and you are now saying
> "the RARP is a false one __created__ by the vhost backend".
>
> Thanks.
>
> --yliu
>

After a migration, to avoid netwotk outage, all interfaces of the guest
must send a packet to update switches mapping (ideally a GARP).
As some interfaces do not do it QEMU does it in behalf of the guest by
sending a RARP (his RARP is not forged by the guest but by QEMU). This is
the qemu_self_announce purpose that "spoofs" a RARP to all backend of guest
ethernet interfaces. For vhost-user backend, QEMU can not do it directly
and asks to the vhost-user backend to do it with the VHOST_USER_SEND_RARP
request that contains the MAC address of the guest interface.

Thibaut.

[dpdk-dev] [PATCH] i40e: fix set max frame size to default

[Zhang, Helin]

-Original Message-
From: Wu, Jingjing 
Sent: Tuesday, December 15, 2015 10:53 PM
To: dev at dpdk.org
Cc: Wu, Jingjing ; Zhang, Helin ; Dong, ShijieX 
Subject: [PATCH] i40e: fix set max frame size to default

In FreeBsd driver, the max frame size is changed to MTU, but not keep the 
default value defined in DataSheet. When DPDK runs on that NIC, the configured 
value is not expected.
This patch sets the max frame size to default when initialization.

Fixes: 4861cde46116 ("i40e: new poll mode driver")

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 

[dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration

[Zhang, Helin]

-Original Message-
From: Nelio Laranjeiro [mailto:nelio.laranje...@6wind.com] 
Sent: Tuesday, December 15, 2015 10:15 PM
To: dev at dpdk.org
Cc: Zhang, Helin ; thomas.monjalon at 6wind.com; Lu, 
Wenzhuo ; adrien.mazarguil at 6wind.com
Subject: [PATCH] doc: fix ABI announce change for RETA configuration

Replace "entries" by "queues", it clarifies the case.

Fixes: bd3cea78abd8 ("doc: announce ABI change for RETA configuration")

Signed-off-by: Nelio Laranjeiro 
Acked-by: Helin Zhang 

[dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag

[Panu Matilainen]

Commit 9cbae2aa64eb managed to break the only previously supported
case where a tag is used as a revision, due to git show output
differing between tags and other objects. The hash is on the last
line of the output in both cases though so just grab that.

Fixes: 9cbae2aa64eb ("scripts: support any git revisions as ABI validation 
range")
Signed-off-by: Panu Matilainen 
---
 scripts/validate-abi.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
index 8d7be24..c36ad61 100755
--- a/scripts/validate-abi.sh
+++ b/scripts/validate-abi.sh
@@ -121,8 +121,8 @@ then
cleanup_and_exit 1
 fi

-HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
-HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
+HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
+HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)

 # Make sure our tags exist
 res=$(validate_tags)
-- 
2.5.0

[dpdk-dev] [PATCH] app/testpmd: fix dead code

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jingjing Wu
> Sent: Tuesday, December 15, 2015 3:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] app/testpmd: fix dead code
> 
> Coverity issue (CID 119254): Control flow issues (DEADCODE).
> 
> Fixes: 1a572499beb6 ("app/testpmd: setup DCB forwarding based on traffic
> class")
> Signed-off-by: Jingjing Wu 

Acked-by: John McNamara 

[dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# Successfully setup DPDK OVS with vhostuser

[Czesnowicz, Przemyslaw]

Hi Abhijeet,

If you answer below questions it will help me understand your problem.

What do you mean by DPDK instance?
Are you able to communicate with other VM's on the same compute node?
Can you check if the DHCP requests arrive on the controller node? (I'm assuming 
this is at least compute+ controller setup)

Best regards
Przemek

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Abhijeet Karve
> Sent: Tuesday, December 15, 2015 5:56 AM
> To: Gray, Mark D
> Cc: dev at dpdk.org; discuss at openvswitch.org
> Subject: Re: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved#
> Successfully setup DPDK OVS with vhostuser
> 
> Dear All,
> 
> After seting up system boot parameters as shown below, the issue is
> resolved now & we are able to successfully setup openvswitch netdev-dpdk
> with vhostuser support.
> 
> __
> ___
> Setup 2 sets of huge pages with different sizes. One for Vhost and another
> for Guest VM.
>  Edit /etc/default/grub.
> GRUB_CMDLINE_LINUX="iommu=pt intel_iommu=on  hugepagesz=1G
> hugepages=10 hugepagesz=2M hugepages=4096"
>  # update-grub
>- Mount the huge pages into different directory.
>   # sudo mount -t hugetlbfs nodev /mnt/huge_2M -o pagesize=2M
>   # sudo mount -t hugetlbfs nodev /mnt/huge_1G -o pagesize=1G
> __
> ___
> 
> At present we are facing an issue in Testing DPDK application on setup. In our
> scenario, We have DPDK instance launched on top of the Openstack Kilo
> compute node. Not able to assign DHCP IP from controller.
> 
> 
> Thanks & Regards
> Abhijeet Karve
> 
> =-=-=
> Notice: The information contained in this e-mail message and/or
> attachments to it may contain confidential or privileged information. If you
> are not the intended recipient, any dissemination, use, review, distribution,
> printing or copying of the information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If you have received this
> communication in error, please notify us by reply e-mail or telephone and
> immediately and permanently delete the message and any attachments.
> Thank you
> 

[dpdk-dev] problem vhost-user sockets

[Pavel Fedin]

 Hello!

 I have a question regarding vhostuser. If we cannot bind to a socket, why do 
we simply fail with error instead of just unlink()ing
the path before binding?

 This causes a very annoying problem with ovs. After ovs is stopped (i use 
supplied system integration), these sockets are not
removed. Looks like ovs just exits without correct cleanup. This effectively 
causes my vhostuser interfaces to go down until i clean
them up manually. And i have to do it after every ovs restart, every system 
reboot, etc. It is very annoying.
 I understand that the app should really do correct cleanup upon exit. But what 
if it abnormally crashes because of some reason
(bug, attack, etc)? Shouldn't it be able to automatically recover?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

[dpdk-dev] [PATCH] doc: announce ABI change for extending filtering support

[Thomas Monjalon]

2015-12-15 19:40, Rahul Lakkireddy:
> Current filtering support will be enhanced to accommodate support
> for Chelsio T5 hardware filtering support.
> 
> Signed-off-by: Rahul Lakkireddy 
> Signed-off-by: Kumar Sanghvi 
> ---
>  doc/guides/rel_notes/deprecation.rst | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index f8a41dd..15e766d 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -41,3 +41,11 @@ Deprecation Notices
>commands (such as RETA update in testpmd).  This should impact
>CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE.
>It should be integrated in release 2.3.
> +
> +* ABI changes are planned for rte_eth_ipv4_flow and rte_eth_ipv6_flow to
> +  include more fields to be matched against. The release 2.2 does not
> +  contain these ABI changes, but release 2.3 will.
> +
> +* ABI changes are planned for adding four new flow types. This impacts
> +  RTE_ETH_FLOW_MAX. The release 2.2 does not contain these ABI changes,
> +  but release 2.3 will.

They were already other ABI changes planned for flow director.
So it doesn't hurt to merge this announce, and we'll with the coming patches
if the new flows can be accepted.

Acked-by: Thomas Monjalon 
Applied

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Pavel Fedin]

 Hello!

> After a migration, to avoid network outage, the guest must announce its new 
> location to the L2 layer, typically with a GARP. Otherwise requests sent to
> the guest arrive to the old host until a ARP request is sent (after 30 
> seconds) or the guest sends some data.
> QEMU implementation of self announce after a migration with a vhost backend 
> is the following:
> - If the VIRTIO_GUEST_ANNOUNCE feature has been negotiated the guest sends 
> automatically a GARP.
> - Else if the vhost backend implements VHOST_USER_SEND_RARP this request is 
> sent to the vhost backend. When this message is received the vhost backend
> must act as it receives a RARP from the guest (purpose of this RARP is to 
> update switches' MAC->port maaping as a GARP). This RARP is a false one,
> created by the vhost backend,
> - Else nothing is done and we have a network outage until a ARP is sent or 
> the guest sends some data.

 But what is qemu_announce_self() then? It's just unconditionally triggered 
after migration, but indeed sends some strange thing.

> VIRTIO_GUEST_ANNOUNCE feature is negotiated if:
>  - the vhost backend announces the support of this feature. Maybe QEMU can be 
> updated to support unconditionnaly this feature

 Wrong. I tried to unconditionally enforce it in qemu (my guest does support 
it), and the link stopped working at all. I don't understand why.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

[dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag

[Thomas Monjalon]

2015-12-15 09:16, Neil Horman:
> On Tue, Dec 15, 2015 at 03:55:15PM +0200, Panu Matilainen wrote:
> > Commit 9cbae2aa64eb managed to break the only previously supported
> > case where a tag is used as a revision, due to git show output
> > differing between tags and other objects. The hash is on the last
> > line of the output in both cases though so just grab that.
> > 
> > Fixes: 9cbae2aa64eb ("scripts: support any git revisions as ABI validation 
> > range")
> > Signed-off-by: Panu Matilainen 
> > ---
> >  scripts/validate-abi.sh | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
> > index 8d7be24..c36ad61 100755
> > --- a/scripts/validate-abi.sh
> > +++ b/scripts/validate-abi.sh
> > @@ -121,8 +121,8 @@ then
> > cleanup_and_exit 1
> >  fi
> >  
> > -HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
> > -HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
> > +HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
> > +HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)
> >  
> >  # Make sure our tags exist
> >  res=$(validate_tags)
> Acked-by: Neil Horman 

Applied, thanks

[dpdk-dev] [PATCH] doc: fix ABI announce change for RETA configuration

[Nelio Laranjeiro]

Replace "entries" by "queues", it clarifies the case.

Fixes: bd3cea78abd8 ("doc: announce ABI change for RETA configuration")

Signed-off-by: Nelio Laranjeiro 
---
 doc/guides/rel_notes/deprecation.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index f8a41dd..afab2ed 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -16,8 +16,8 @@ Deprecation Notices
   must be updated to support 100G link and to have a cleaner link speed API.

 * ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
-  which handles at most 256 entries (8 bits) while newer NICs support larger
-  tables (512 entries).
+  which handles at most 256 queues (8 bits) while newer NICs support larger
+  tables (512 queues).
   It should be integrated in release 2.3.

 * ABI changes are planned for struct rte_eth_fdir_flow in order to support
-- 
2.1.4

[dpdk-dev] [PATCH] doc: show -n as optional in freebsd user guide

[Thomas Monjalon]

2015-12-15 13:47, John McNamara:
> Fix EAL usage to indicate that -n is, now, optional.
> 
> Signed-off-by: John McNamara 

Applied, thanks

[dpdk-dev] [PATCH] doc: improve linux guide layout

[Thomas Monjalon]

2015-12-15 13:34, John McNamara:
> Fixed Linux Getting Started Guide rst layout to improve
> rendering in PDF.
> 
> Signed-off-by: John McNamara 

Applied, thanks

[dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support

[Thomas Monjalon]

2015-12-15 19:21, Rahul Lakkireddy:
> Hi Thomas,
> 
> On Tuesday, December 12/15/15, 2015 at 00:55:20 -0800, Thomas Monjalon wrote:
> > 2015-12-15 14:10, Rahul Lakkireddy:
> > > Hi Thomas,
> > > 
> > > I am preparing a v2 of this series where I will be accomodating some
> > > more fields to be considered for filtering. However, if the overall
> > > approach seems ok to everyone then, should I submit a separate patch
> > > for this ABI change announcement ?
> > 
> > Yes, if this announce is not enough:
> > http://dpdk.org/browse/dpdk/commit/?id=648e6b3815a35
> > 
> 
> Apart from rte_eth_fdir_flow ABI change mentioned in above link, new
> fields will be added to rte_eth_ipv4_flow and rte_eth_ipv6_flow,
> which break their ABI.
> 
> Also, 4 new flow types will be added, which increases RTE_ETH_FLOW_MAX
> from 18 to 22 and breaks the ABI.
> 
> Should I send a separate ABI change announce patch for each of them?

Yes please send a patch (1 is enough).
You have less than 30 minutes :)

[dpdk-dev] releases scheduling

[Wiles, Keith]

On 12/15/15, 7:37 AM, "dev on behalf of O'Driscoll, Tim"  wrote:

>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>> Sent: Sunday, December 13, 2015 7:23 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] releases scheduling
>> 
>> Hi all,
>> 
>> We need to define the deadlines for the next releases.
>> During 2015, we were doing a release every 4 months.
>> If we keep the same pace, the next releases would be:
>>  2.3: end of March
>>  2.4: end of July
>>  2.5: end of November
>> 
>> However, things move fast and it may be a bit long to wait 4 months for
>> a feature. That's why I suggest to progressively shorten release terms:
>>  2.3: end of March
>>  2.4: mid July
>>  2.5: end of October
>> and continue with a release every 3 months:
>>  2.6: end of January
>>  2.7: end of April
>>  2.8: end of July
>> This planning would preserve some of the major holiday periods
>> (February, May, August, December).
>> 
>> The first period, for the first submission of a feature, was 2 months
>> long.
>> Then we had 2 other months to discuss, merge and fix.
>> We should shorten only the first period.
>> 
>> Anyway, the next deadlines should be unchanged:
>>  - January 31: end of first submission phase
>>  - March 31: release 2.3
>> 
>> Opinions are welcome.
>
>I think moving to quarterly releases is a good idea. Your proposal to do this 
>in a gradual way, so that we don't change the 2.3 dates, also makes sense.
>
>Should we consider changing the release numbering at the same time? It's 
>difficult to keep track of when each 2.x release is due, and we don't have any 
>criteria in place for moving to 3.x in future. Many people like the Ubuntu 
>numbering scheme of Year.Month. Should we consider adopting that convention? 
>If we move in future to a model where we have long-term support releases 
>(something that was touched on in Dublin), then we could append an LTS 
>designation to the release number.

+1 for the Ubuntu number and the LTS
>
>
>Tim
>


Regards,
Keith

[dpdk-dev] [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers.

[Ananyev, Konstantin]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Monday, December 14, 2015 9:35 PM
> To: Ananyev, Konstantin
> Cc: Zhang, Helin; dev at dpdk.org; Tom Kiely
> Subject: Re: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers.
> 
> On Mon, 14 Dec 2015 19:57:10 +
> "Ananyev, Konstantin"  wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > > Sent: Monday, December 14, 2015 7:25 PM
> > > To: Ananyev, Konstantin
> > > Cc: Zhang, Helin; dev at dpdk.org; Tom Kiely
> > > Subject: Re: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers.
> > >
> > > On Mon, 14 Dec 2015 19:12:26 +
> > > "Ananyev, Konstantin"  wrote:
> > >
> > > >
> > > >
> > > > > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > > > > Sent: Friday, December 11, 2015 4:59 PM
> > > > > To: Zhang, Helin; Ananyev, Konstantin
> > > > > Cc: dev at dpdk.org; Tom Kiely; Stephen Hemminger
> > > > > Subject: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers.
> > > > >
> > > > > From: Tom Kiely 
> > > > >
> > > > > SRIOV VFs support "transparent" vlans. Traffic from/to a VM
> > > > > associated with a VF is tagged/untagged with the specified
> > > > > vlan in a manner intended to be totally transparent to the VM.
> > > > >
> > > > > The vlan is specified by "ip link set  vf  vlan ".
> > > > > The VM is not configured for any vlan on the VF and the VM
> > > > > should never see these transparent vlan headers for that reason.
> > > > >
> > > > > However, in practice these vlan headers are being received by
> > > > > the VM which discards the packets as that vlan is unknown to it.
> > > > > The Linux kernel explicitly discards such vlan headers but DPDK
> > > > > does not.
> > > > > This patch mirrors the kernel behaviour for SRIOV VFs only
> > > >
> > > >
> > > > I have few concerns about that approach:
> > > >
> > > > 1. I don't think vlan_tci info should *always* be stripped by vf RX 
> > > > routine.
> > > > There could be configurations when that information might be needed by 
> > > > upper layer.
> > > > Let say VF can be member of 2 or more VLANs and upper layer would like 
> > > > to have that information
> > > > for further processing.
> > > > Or special mirror VF, that does traffic snnoping, or something else.
> > > > 2. Proposed implementation would introduce a slowdown for all VF RX 
> > > > routines.
> > > > 3. From the description it seems like the aim is to clear VLAN 
> > > > information for the RX packet.
> > > > Though the patch actually clears VLAN info only for the RX packet whose 
> > > > VLAN tag is not present inside SW copy of VFTA table.
> > > > Which makes no much point to me:
> > > > If VLAN is not present in HW VFTA table, then packet with that VLAN tag 
> > > > will be discarded by HW anyway.
> > > > If it is present inside VFTA table (both SW & HW), then VLAN 
> > > > information would be preserved with and without the patch.
> > > >
> > > > If you need to clear VLAN information, why not to do it on the upper 
> > > > layer - inside your application itself?
> > > > Either create some sort of wrapper around rx_burst(), or setup an RX 
> > > > call-back for your VF device.
> > > >
> > > > Konstantin
> > >
> > >
> > > The aim is to get SRIOV to work when the transparent VLAN tag feature is 
> > > used.
> > > Please talk to the Linux driver team. Similar code exists there in 
> > > ixgbevf_process_skb_fields.
> >
> >
> > Ah ok, I realised what you are trying to achieve now:
> > You setup HW VFTA[] from the PF, so from VF point of view SW copy of the 
> > VFTA[] remains unset.
> > So HW will pass VLAN packet in, but then SW will clear VLAN tag.
> > Ok, that clears #3 above, but I think #1,2 still remain.
> 
> On the host, what configured is a vlan tag per VF per guest
> 
> Tom had more info in the original mail.
> 
> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/28932
> 
> > >
> > > The other option is have a copy of all the receive logic which is only
> > > used by VF code.
> >
> > Why that's the only option?
> > Why can't you clear that VLAN information above the PMD layer?
> > Keep/obtain a copy of VFTA[] somewhere on the upper layer,
> > and do actual clear after rx_burst() returns?
> > Konstantin
> 
> The problem is that the guest is supposed to not see the VLAN tags (it has no 
> reason to),
> but the hardware leaves a VLAN tag on there.

Yes, I understand what you are trying to achieve.
 What I am trying to say:
1. VLAN tag removing shouldn't be forced for all VFs.
I think there are scenarios where existing behaviour (keeping vlan_tci and 
ol_flags intact) are what people need.
One example would be mirror VF doing other VFs traffic snooping.
Probably some other cases too.
2. The way you implemented it - it might cause a RX performance degradation 
(specially for VF).
That's why I think it better to be implemented on top of PMD:
i.e: some sor

[dpdk-dev] releases scheduling

[Dave Neary]

Hi,

You could just bump the major version for the first release of the new
year - in this case, we would make 2.6 be 3.0. It achieves the same
objective without having a big discontinuity in the release numbers.

Thanks,
Dave.



On 12/15/2015 08:37 AM, O'Driscoll, Tim wrote:
> 
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
>> Sent: Sunday, December 13, 2015 7:23 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] releases scheduling
>>
>> Hi all,
>>
>> We need to define the deadlines for the next releases.
>> During 2015, we were doing a release every 4 months.
>> If we keep the same pace, the next releases would be:
>>  2.3: end of March
>>  2.4: end of July
>>  2.5: end of November
>>
>> However, things move fast and it may be a bit long to wait 4 months for
>> a feature. That's why I suggest to progressively shorten release terms:
>>  2.3: end of March
>>  2.4: mid July
>>  2.5: end of October
>> and continue with a release every 3 months:
>>  2.6: end of January
>>  2.7: end of April
>>  2.8: end of July
>> This planning would preserve some of the major holiday periods
>> (February, May, August, December).
>>
>> The first period, for the first submission of a feature, was 2 months
>> long.
>> Then we had 2 other months to discuss, merge and fix.
>> We should shorten only the first period.
>>
>> Anyway, the next deadlines should be unchanged:
>>  - January 31: end of first submission phase
>>  - March 31: release 2.3
>>
>> Opinions are welcome.
> 
> I think moving to quarterly releases is a good idea. Your proposal to do this 
> in a gradual way, so that we don't change the 2.3 dates, also makes sense.
> 
> Should we consider changing the release numbering at the same time? It's 
> difficult to keep track of when each 2.x release is due, and we don't have 
> any criteria in place for moving to 3.x in future. Many people like the 
> Ubuntu numbering scheme of Year.Month. Should we consider adopting that 
> convention? If we move in future to a model where we have long-term support 
> releases (something that was touched on in Dublin), then we could append an 
> LTS designation to the release number.
> 
> 
> Tim
> 

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

[dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support

[Rahul Lakkireddy]

Hi Thomas,

I am preparing a v2 of this series where I will be accomodating some
more fields to be considered for filtering. However, if the overall
approach seems ok to everyone then, should I submit a separate patch
for this ABI change announcement ?


Thanks,
Rahul.

On Thursday, December 12/10/15, 2015 at 19:31:04 +0530, Rahul Lakkireddy wrote:
> Current filtering support will be enhanced to accommodate support
> for Chelsio T5 hardware filtering support.
> 
> Signed-off-by: Rahul Lakkireddy 
> Signed-off-by: Kumar Sanghvi 
> ---
>  doc/guides/rel_notes/deprecation.rst | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index 1c7ab01..ca43b16 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -19,3 +19,9 @@ Deprecation Notices
>and table action handlers will be updated:
>the pipeline parameter will be added, the packets mask parameter will be
>either removed (for input port action handler) or made input-only.
> +
> +* The filtering support will be changed to add a new packet filter
> +  flow, add a new behavior 'switch', add an ability to add mask
> +  for fields in each filter rule, and add an ability to pass extra
> +  arguments for the behavior taken to allow rewriting matched fields
> +  in filter rule.
> -- 
> 2.5.3
> 

[dpdk-dev] [PATCH 2/2] ethdev: remove old flow director symbols

[Thomas Monjalon]

2015-12-15 13:41, Panu Matilainen:
> On 12/15/2015 12:47 PM, Thomas Monjalon wrote:
> > The API has been removed but the symbols were still declared in the map.
> >
> > Fixes: a421b86a4a02 ("ethdev: remove old flow director API")
> >
> > Signed-off-by: Thomas Monjalon 
[...]
> 
> Good spotting. What did you use find these and the ones in eal? Just 
> thinking this seems like something that could and should be automated.

Series applied

[dpdk-dev] [PATCH] doc: announce ABI change for link speed

[Thomas Monjalon]

> > A rework was prepared by Marc Sune:
> > http://dpdk.org/ml/archives/dev/2015-October/026037.html
> > The goal is to retrieve the supported link speed of a device
> > and to allow 100G devices while having a consistent API.
> >
> > Signed-off-by: Thomas Monjalon 
> Acked-by: Olga Shern 
> Acked-by: Adrien Mazarguil 
> Acked-by: Jan Viktorin 
> Acked-by: Matej Vido 

Applied, thanks

[dpdk-dev] [PATCH] doc: include ixgbe rx error changes

[Thomas Monjalon]

> > This patch updates the release notes to include the changes made (by me),
> > which were not appropriatly documented at the time.
> > Hence, this patch fixes a number of missing docs,
> > 
> > Fixes: e81a315e5dc5 ("ixgbe: add MAC short packet discard count to Rx
> > errors")
> > Fixes: 48dd1a82a615 ("ixgbe: remove mac fault counts from Rx errors")
> > Fixes: 256ff05a9cae ("ixgbe: fix Rx errors statistics for UDP checksum")
> > 
> > Also, the CRC byte removal was not added to release notes, so
> > Fixes: 156c5a8cf913 ("e1000: remove CRC size from byte counters")
> > Fixes: c03fcee9abbd ("ixgbe: remove CRC size from byte counters")
> > Fixes: 0834d1524dee ("i40e: remove CRC size from byte counters")
> > 
> > Signed-off-by: Harry van Haaren 
> 
> Acked-by: John McNamara 

Applied, thanks

[dpdk-dev] [PATCH] doc: show -n as optional in freebsd user guide

[John McNamara]

Fix EAL usage to indicate that -n is, now, optional.

Signed-off-by: John McNamara 
---
 doc/guides/freebsd_gsg/build_sample_apps.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst 
b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 823e1fb..2662303 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -119,7 +119,7 @@ The following is the list of options that can be given to 
the EAL:

 .. code-block:: console

-./rte-app -n NUM [-c COREMASK] [-b ] \
+./rte-app -c COREMASK [-n NUM] [-b ] \
   [-r NUM] [-v] [--proc-type ]

 .. note::
-- 
2.5.0

[dpdk-dev] [PATCH] doc: improve freebsd guide layout

[Thomas Monjalon]

2015-12-15 11:53, John McNamara:
> Fixed FreeBSD Getting Started Guide rst layout to improve
> rendering in PDF.
> 
> Signed-off-by: John McNamara 

Applied, thanks

[dpdk-dev] [PATCH] doc: remove unused references from faq

[Thomas Monjalon]

2015-12-15 11:12, John McNamara:
> The faq refers to Linux*, with an asterisk, without any equivalent
> note or footnote. This is a legacy from older versions of the docs.
> This update removes it.
> 
> Signed-off-by: John McNamara 

Applied, thanks

[dpdk-dev] VFIO no-iommu

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Williamson
> Sent: Friday, December 11, 2015 11:03 PM
> To: Vincent JARDIN; dev at dpdk.org
> Subject: Re: [dpdk-dev] VFIO no-iommu
> 
> On Fri, 2015-12-11 at 23:12 +0100, Vincent JARDIN wrote:
> > Thanks Thomas for putting back this topic.
> >
> > Alex,
> >
> > I'd like to hear more about the impacts of "unsupported":
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi
> > t/?id=033291eccbdb1b70ffc02641edae19ac825dc75d
> > ???Use of this mode, specifically binding a device without a native
> > ???IOMMU group to a VFIO bus driver will taint the kernel and should
> > ???therefore not be considered supported.
> >
> > It means that we get ride of uio; so it is a nice code cleanup: but
> > why
> > would VFIO/NO IOMMU be better if the bottomline is "unsupported"?
> 
> How supportable do you think the uio method is? ?Fundamentally we have
> a userspace driver doing unrestricted DMA; it can access and modify any
> memory in the system. ?This is the reason uio won't provide a mechanism
> to enable MSI and if you ask the uio maintainer, they don't support DMA
> at all, it's only intended as a programmed IO interface to the device.
> ?Unless we can sandbox a user owned device within an IOMMU protected
> container, it's not supportable. ?The VFIO no-iommu mode can simply
> provide you that unsupported mode more easily since it leverages code
> from the supported mode, which is IOMMU protected. ?Thanks,

Thanks for clarifying.

This does seem like it would be useful for DPDK. We're doing some further 
investigation to see if it works out of the box with DPDK or if we need to make 
any changes to support it.

Thomas highlighted that your original commit for this had been reverted. What 
specifically would you need from us in order to re-submit the VFIO No-IOMMU 
support?


Tim

> 
> Alex

[dpdk-dev] [PATCH 2/2] ethdev: remove old flow director symbols

[Panu Matilainen]

On 12/15/2015 12:47 PM, Thomas Monjalon wrote:
> The API has been removed but the symbols were still declared in the map.
>
> Fixes: a421b86a4a02 ("ethdev: remove old flow director API")
>
> Signed-off-by: Thomas Monjalon 
> ---
>   lib/librte_ether/rte_ether_version.map | 8 
>   1 file changed, 8 deletions(-)
>
> diff --git a/lib/librte_ether/rte_ether_version.map 
> b/lib/librte_ether/rte_ether_version.map
> index 17a11c7..d8db24d 100644
> --- a/lib/librte_ether/rte_ether_version.map
> +++ b/lib/librte_ether/rte_ether_version.map
> @@ -27,14 +27,6 @@ DPDK_2.2 {
>   rte_eth_dev_count;
>   rte_eth_dev_default_mac_addr_set;
>   rte_eth_dev_detach;
> - rte_eth_dev_fdir_add_perfect_filter;
> - rte_eth_dev_fdir_add_signature_filter;
> - rte_eth_dev_fdir_get_infos;
> - rte_eth_dev_fdir_remove_perfect_filter;
> - rte_eth_dev_fdir_remove_signature_filter;
> - rte_eth_dev_fdir_set_masks;
> - rte_eth_dev_fdir_update_perfect_filter;
> - rte_eth_dev_fdir_update_signature_filter;
>   rte_eth_dev_filter_ctrl;
>   rte_eth_dev_filter_supported;
>   rte_eth_dev_flow_ctrl_get;
>

Good spotting. What did you use find these and the ones in eal? Just 
thinking this seems like something that could and should be automated.

- Panu -

[dpdk-dev] releases scheduling

[O'Driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Sunday, December 13, 2015 7:23 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] releases scheduling
> 
> Hi all,
> 
> We need to define the deadlines for the next releases.
> During 2015, we were doing a release every 4 months.
> If we keep the same pace, the next releases would be:
>   2.3: end of March
>   2.4: end of July
>   2.5: end of November
> 
> However, things move fast and it may be a bit long to wait 4 months for
> a feature. That's why I suggest to progressively shorten release terms:
>   2.3: end of March
>   2.4: mid July
>   2.5: end of October
> and continue with a release every 3 months:
>   2.6: end of January
>   2.7: end of April
>   2.8: end of July
> This planning would preserve some of the major holiday periods
> (February, May, August, December).
> 
> The first period, for the first submission of a feature, was 2 months
> long.
> Then we had 2 other months to discuss, merge and fix.
> We should shorten only the first period.
> 
> Anyway, the next deadlines should be unchanged:
>   - January 31: end of first submission phase
>   - March 31: release 2.3
> 
> Opinions are welcome.

I think moving to quarterly releases is a good idea. Your proposal to do this 
in a gradual way, so that we don't change the 2.3 dates, also makes sense.

Should we consider changing the release numbering at the same time? It's 
difficult to keep track of when each 2.x release is due, and we don't have any 
criteria in place for moving to 3.x in future. Many people like the Ubuntu 
numbering scheme of Year.Month. Should we consider adopting that convention? If 
we move in future to a model where we have long-term support releases 
(something that was touched on in Dublin), then we could append an LTS 
designation to the release number.


Tim

[dpdk-dev] [ [PATCH v2] 06/13] config: armv7/v8: Enable RTE_LIBRTE_VIRTIO_PMD

[Jianbo Liu]

On 14 December 2015 at 21:00, Santosh Shukla  wrote:
> Enable RTE_LIBRTE_VIRTIO_PMD for armv7/v8 and setting RTE_VIRTIO_INC_VEC=n.
> Builds successfully for armv7/v8.
>
> Signed-off-by: Santosh Shukla 
> ---
>  config/defconfig_arm-armv7a-linuxapp-gcc   |6 +-
>  config/defconfig_arm64-armv8a-linuxapp-gcc |6 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
> b/config/defconfig_arm-armv7a-linuxapp-gcc
> index cbebd64..d840dc2 100644
> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> @@ -43,6 +43,11 @@ CONFIG_RTE_FORCE_INTRINSICS=y
>  CONFIG_RTE_TOOLCHAIN="gcc"
>  CONFIG_RTE_TOOLCHAIN_GCC=y
>
> +# VIRTIO support for ARM
> +CONFIG_RTE_LIBRTE_VIRTIO_PMD=y

I don't think the above line is needed since already enabled in
config/common_linuxapp.

> +# Disable VIRTIO VECTOR support
> +CONFIG_RTE_VIRTIO_INC_VECTOR=n
> +
>  # ARM doesn't have support for vmware TSC map
>  CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
>
> @@ -70,7 +75,6 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
>  CONFIG_RTE_LIBRTE_IXGBE_PMD=n
>  CONFIG_RTE_LIBRTE_MLX4_PMD=n
>  CONFIG_RTE_LIBRTE_MPIPE_PMD=n
> -CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
>  CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
>  CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
>  CONFIG_RTE_LIBRTE_PMD_BNX2X=n
> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
> b/config/defconfig_arm64-armv8a-linuxapp-gcc
> index 504f3ed..b3a4b28 100644
> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> @@ -45,8 +45,12 @@ CONFIG_RTE_TOOLCHAIN_GCC=y
>
>  CONFIG_RTE_CACHE_LINE_SIZE=64
>
> +# Enable VIRTIO support for ARM
> +CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
> +# Disable VIRTIO VECTOR support
> +CONFIG_RTE_VIRTIO_INC_VECTOR=n
> +
>  CONFIG_RTE_IXGBE_INC_VECTOR=n
> -CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
>  CONFIG_RTE_LIBRTE_IVSHMEM=n
>  CONFIG_RTE_LIBRTE_FM10K_PMD=n
>  CONFIG_RTE_LIBRTE_I40E_PMD=n
> --
> 1.7.9.5
>

[dpdk-dev] [PATCH] doc: improve linux guide layout

[John McNamara]

Fixed Linux Getting Started Guide rst layout to improve
rendering in PDF.

Signed-off-by: John McNamara 
---
 doc/guides/linux_gsg/build_dpdk.rst|  88 +-
 doc/guides/linux_gsg/build_sample_apps.rst | 141 +
 doc/guides/linux_gsg/enable_func.rst   |  95 ++-
 doc/guides/linux_gsg/intro.rst |   8 +-
 doc/guides/linux_gsg/quick_start.rst   |  25 ++---
 doc/guides/linux_gsg/sys_reqs.rst  | 114 ---
 6 files changed, 234 insertions(+), 237 deletions(-)

diff --git a/doc/guides/linux_gsg/build_dpdk.rst 
b/doc/guides/linux_gsg/build_dpdk.rst
index c4d1e08..1f4c1f7 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -28,14 +28,13 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-.. _linux_gsg_compiling_dpdk:
-
 Compiling the DPDK Target from Source
 =

 .. note::

-Parts of this process can also be done using the setup script described in 
Chapter 6 of this document.
+Parts of this process can also be done using the setup script described in
+the :ref:`linux_setup_script` section of this document.

 Install the DPDK and Browse Sources
 ---
@@ -44,10 +43,12 @@ First, uncompress the archive and move to the uncompressed 
DPDK source directory

 .. code-block:: console

-   user at host:~$ unzip DPDK-.zip
-   user at host:~$ cd DPDK-
-   user at host:~/DPDK-$ ls
-   app/   config/   drivers/   examples/   lib/   LICENSE.GPL   LICENSE.LGPL   
Makefile   mk/   scripts/   tools/
+unzip DPDK-.zip
+cd DPDK-
+
+ls
+app/ config/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefile
+mk/ scripts/ tools/

 The DPDK is composed of several directories:

@@ -64,19 +65,19 @@ The DPDK is composed of several directories:
 Installation of DPDK Target Environments
 

-The format of a DPDK target is:
+The format of a DPDK target is::

 ARCH-MACHINE-EXECENV-TOOLCHAIN

 where:

-*   ARCH can be:  i686, x86_64, ppc_64
+* ``ARCH`` can be:  ``i686``, ``x86_64``, ``ppc_64``

-*   MACHINE can be:  native, ivshmem, power8
+* ``MACHINE`` can be:  ``native``, ``ivshmem``, ``power8``

-*   EXECENV can be:  linuxapp,  bsdapp
+* ``EXECENV`` can be:  ``linuxapp``,  ``bsdapp``

-*   TOOLCHAIN can be:  gcc,  icc
+* ``TOOLCHAIN`` can be:  ``gcc``,  ``icc``

 The targets to be installed depend on the 32-bit and/or 64-bit packages and 
compilers installed on the host.
 Available targets can be found in the DPDK/config directory.
@@ -84,13 +85,13 @@ The defconfig\_ prefix should not be used.

 .. note::

-Configuration files are provided with the RTE_MACHINE optimization level 
set.
-Within the configuration files, the RTE_MACHINE configuration value is set 
to native,
+Configuration files are provided with the ``RTE_MACHINE`` optimization 
level set.
+Within the configuration files, the ``RTE_MACHINE`` configuration value is 
set to native,
 which means that the compiled software is tuned for the platform on which 
it is built.
 For more information on this setting, and its possible values, see the 
*DPDK Programmers Guide*.

 When using the Intel? C++ Compiler (icc), one of the following commands should 
be invoked for 64-bit or 32-bit use respectively.
-Notice that the shell scripts update the $PATH variable and therefore should 
not be performed in the same session.
+Notice that the shell scripts update the ``$PATH`` variable and therefore 
should not be performed in the same session.
 Also, verify the compiler's installation directory since the path may be 
different:

 .. code-block:: console
@@ -98,7 +99,7 @@ Also, verify the compiler's installation directory since the 
path may be differe
 source /opt/intel/bin/iccvars.sh intel64
 source /opt/intel/bin/iccvars.sh ia32

-To install and make targets, use the make install T= command in the 
top-level DPDK directory.
+To install and make targets, use the ``make install T=`` command in 
the top-level DPDK directory.

 For example, to compile a 64-bit target using icc, run:

@@ -113,7 +114,7 @@ To compile a 32-bit build using gcc, the make command 
should be:
 make install T=i686-native-linuxapp-gcc

 To prepare a target without building it, for example, if the configuration 
changes need to be made before compilation,
-use the make config T= command:
+use the ``make config T=`` command:

 .. code-block:: console

@@ -121,10 +122,10 @@ use the make config T= command:

 .. warning::

-Any kernel modules to be used, e.g. igb_uio, kni, must be compiled with the
+Any kernel modules to be used, e.g. ``igb_uio``, ``kni``, must be compiled 
with the
 same kernel as the one running on the target.
 If the DPDK is not being built on the target machine,
-the RTE_KERNEL

[dpdk-dev] [PATCH 2/2] ethdev: remove old flow director symbols

[Thomas Monjalon]

2015-12-15 13:41, Panu Matilainen:
> On 12/15/2015 12:47 PM, Thomas Monjalon wrote:
> > The API has been removed but the symbols were still declared in the map.
> >
> > Fixes: a421b86a4a02 ("ethdev: remove old flow director API")
> >
> > Signed-off-by: Thomas Monjalon 
> > ---
> >   lib/librte_ether/rte_ether_version.map | 8 
> >   1 file changed, 8 deletions(-)
> >
> > diff --git a/lib/librte_ether/rte_ether_version.map 
> > b/lib/librte_ether/rte_ether_version.map
> > index 17a11c7..d8db24d 100644
> > --- a/lib/librte_ether/rte_ether_version.map
> > +++ b/lib/librte_ether/rte_ether_version.map
> > @@ -27,14 +27,6 @@ DPDK_2.2 {
> > rte_eth_dev_count;
> > rte_eth_dev_default_mac_addr_set;
> > rte_eth_dev_detach;
> > -   rte_eth_dev_fdir_add_perfect_filter;
> > -   rte_eth_dev_fdir_add_signature_filter;
> > -   rte_eth_dev_fdir_get_infos;
> > -   rte_eth_dev_fdir_remove_perfect_filter;
> > -   rte_eth_dev_fdir_remove_signature_filter;
> > -   rte_eth_dev_fdir_set_masks;
> > -   rte_eth_dev_fdir_update_perfect_filter;
> > -   rte_eth_dev_fdir_update_signature_filter;
> > rte_eth_dev_filter_ctrl;
> > rte_eth_dev_filter_supported;
> > rte_eth_dev_flow_ctrl_get;
> >
> 
> Good spotting. What did you use find these and the ones in eal? Just 
> thinking this seems like something that could and should be automated.

Yes, it must be automated.
There are also some symbols which are defined in headers and do not need
to be in the .map. I'll send more cleanup and the script in the coming days
(for 2.3).

[dpdk-dev] [PATCH] doc: announce ABI change for link speed

[Matej Vido]

Acked-by: Matej Vido 

D?a 15.12.2015 o 08:21 Thomas Monjalon nap?sal(a):
> A rework was prepared by Marc Sune:
> http://dpdk.org/ml/archives/dev/2015-October/026037.html
> The goal is to retrieve the supported link speed of a device
> and to allow 100G devices while having a consistent API.
>
> Signed-off-by: Thomas Monjalon 

[dpdk-dev] [PATCH] doc: include ixgbe rx error changes

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Harry van Haaren
> Sent: Tuesday, December 15, 2015 12:11 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: include ixgbe rx error changes
> 
> This patch updates the release notes to include the changes made (by me),
> which were not appropriatly documented at the time.
> Hence, this patch fixes a number of missing docs,
> 
> Fixes: e81a315e5dc5 ("ixgbe: add MAC short packet discard count to Rx
> errors")
> Fixes: 48dd1a82a615 ("ixgbe: remove mac fault counts from Rx errors")
> Fixes: 256ff05a9cae ("ixgbe: fix Rx errors statistics for UDP checksum")
> 
> Also, the CRC byte removal was not added to release notes, so
> Fixes: 156c5a8cf913 ("e1000: remove CRC size from byte counters")
> Fixes: c03fcee9abbd ("ixgbe: remove CRC size from byte counters")
> Fixes: 0834d1524dee ("i40e: remove CRC size from byte counters")
> 
> Signed-off-by: Harry van Haaren 

Acked-by: John McNamara 

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Thibaut Collet]

On Tue, Dec 15, 2015 at 12:43 PM, Thibaut Collet 
wrote:

>
>
> On Tue, Dec 15, 2015 at 11:05 AM, Peter Xu  wrote:
>
>> On Tue, Dec 15, 2015 at 11:45:56AM +0300, Pavel Fedin wrote:
>> >  To tell the truth, i don't know. I am also learning qemu internals on
>> the fly. Indeed, i see that it should announce itself. But
>> > this brings up a question: why do we need special announce procedure in
>> vhost-user then?
>>
>> I have the same question. Here is my guess...
>>
>> In customized networks, maybe people are not using ARP at all? When
>> we use DPDK, we directly pass through the network logic inside
>> kernel itself. So logically all the network protocols could be
>> customized by the user of it. In the customized network, maybe there
>> is some other protocol (rather than RARP) that would do the same
>> thing as what ARP/RARP does. So, this SEND_RARP request could give
>> the vhost-user backend a chance to format its own announce packet
>> and broadcast (in the SEND_RARP request, the guest's mac address
>> will be appended).
>>
>> CCing Victor to better know the truth...
>>
>> Peter
>>
>
>
> Hi,
>
> After a migration, to avoid network outage, the guest must announce its
> new location to the L2 layer, typically with a GARP. Otherwise requests
> sent to the guest arrive to the old host until a ARP request is sent (after
> 30 seconds) or the guest sends some data.
>
> QEMU implementation of self announce after a migration with a vhost
> backend is the following:
>  - If the VIRTIO_GUEST_ANNOUNCE feature has been negotiated the guest
> sends automatically a GARP.
>  - Else if the vhost backend implements VHOST_USER_SEND_RARP this request
> is sent to the vhost backend. When this message is received the vhost
> backend must act as it receives a RARP from the guest (purpose of this RARP
> is to update switches' MAC->port maaping as a GARP). This RARP is a false
> one, created by the vhost backend,
>  - Else nothing is done and we have a network outage until a ARP is sent
> or the guest sends some data.
>
>
> VIRTIO_GUEST_ANNOUNCE feature is negotiated if:
>   - the vhost backend announces the support of this feature. Maybe QEMU
> can be updated to support unconditionnaly this feature
>   - the virtio driver of the guest implements this feature. It is not the
> case for old kernel or dpdk virtio pmd.
>
> Regarding dpdk to have a migration of vhost interface with limited network
> outage we have to:
>
>   - Implement management VHOST_USER_SEND_RARP request to emulate a fake
> RARP for guest
>
> To do that we have to consider two kinds of guest:
>   1. Guest with virtio driver implementing VIRTIO_GUEST_ANNOUNCE feature
>   2. Guest with virtio driver that does not have the VIRTIO_GUEST_ANNOUNCE
> feature. This is the case with old kernel or guest running a dpdk (virtio
> pmd of dpdk does not have this feature)
>
> Guest with VIRTIO_GUEST_ANNOUNCE feature sends automatically some GARP
> after a migration if this feature has been negotiated. So the only thing to
> do it is to negotiate the VIRTIO_GUEST_ANNOUNCE feature between QEMU, vhost
> backend and the guest.
> For this kind of guest the vhost-backend must announce the support of
> VIRTIO_GUEST_ANNOUNCE feature. As vhost-backend has no particular action to
> do in this case the support of VIRTIO_GUEST_ANNOUNCE feature can be
> unconditionally set in QEMU in the future.
>
> For guest without VIRTIO_GUEST_ANNOUNCE feature we have to send a fake
> RARP: QEMU knows the MAC address of the guest and can create and broadcast
> a RARP. But in case of vhost-backend QEMU is not able to broadcast this
> fake RARP and must ask to the vhost backend to do it through the
> VHOST_USER_SEND_RARP request. When the vhost backend receives this message
> it must create a fake RARP message (as done by QEMU) and do the appropriate
> operation as this message has been sent by the guest through the virtio
> rings.
>
>
> To solve this point 2 solutions are implemented:
>  - After the migration the guest automatically sends GARP. This solution
> occurs if VIRTIO_GUEST_ANNOUNCE feature has been negotiated between QEMU
> and the guest.
>  * VIRTIO_GUEST_ANNOUNCE
>


Sorry my previous message will be sent by error (it is a draft with rework
in progress)

The full explanation are:

Hi,

After a migration, to avoid network outage, the guest must announce its new
location to the L2 layer, typically with a GARP. Otherwise requests sent to
the guest arrive to the old host until a ARP request is sent (after 30
seconds) or the guest sends some data.

QEMU implementation of self announce after a migration with a vhost backend
is the following:
 - If the VIRTIO_GUEST_ANNOUNCE feature has been negotiated the guest sends
automatically a GARP.
 - Else if the vhost backend implements VHOST_USER_SEND_RARP this request
is sent to the vhost backend. When this message is received the vhost
backend must act as it receives a RARP from the guest (purpose of this RARP
is to update switches' MAC->port m

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Thibaut Collet]

On Tue, Dec 15, 2015 at 11:05 AM, Peter Xu  wrote:

> On Tue, Dec 15, 2015 at 11:45:56AM +0300, Pavel Fedin wrote:
> >  To tell the truth, i don't know. I am also learning qemu internals on
> the fly. Indeed, i see that it should announce itself. But
> > this brings up a question: why do we need special announce procedure in
> vhost-user then?
>
> I have the same question. Here is my guess...
>
> In customized networks, maybe people are not using ARP at all? When
> we use DPDK, we directly pass through the network logic inside
> kernel itself. So logically all the network protocols could be
> customized by the user of it. In the customized network, maybe there
> is some other protocol (rather than RARP) that would do the same
> thing as what ARP/RARP does. So, this SEND_RARP request could give
> the vhost-user backend a chance to format its own announce packet
> and broadcast (in the SEND_RARP request, the guest's mac address
> will be appended).
>
> CCing Victor to better know the truth...
>
> Peter
>


Hi,

After a migration, to avoid network outage, the guest must announce its new
location to the L2 layer, typically with a GARP. Otherwise requests sent to
the guest arrive to the old host until a ARP request is sent (after 30
seconds) or the guest sends some data.

QEMU implementation of self announce after a migration with a vhost backend
is the following:
 - If the VIRTIO_GUEST_ANNOUNCE feature has been negotiated the guest sends
automatically a GARP.
 - Else if the vhost backend implements VHOST_USER_SEND_RARP this request
is sent to the vhost backend. When this message is received the vhost
backend must act as it receives a RARP from the guest (purpose of this RARP
is to update switches' MAC->port maaping as a GARP). This RARP is a false
one, created by the vhost backend,
 - Else nothing is done and we have a network outage until a ARP is sent or
the guest sends some data.


VIRTIO_GUEST_ANNOUNCE feature is negotiated if:
  - the vhost backend announces the support of this feature. Maybe QEMU can
be updated to support unconditionnaly this feature
  - the virtio driver of the guest implements this feature. It is not the
case for old kernel or dpdk virtio pmd.

Regarding dpdk to have a migration of vhost interface with limited network
outage we have to:

  - Implement management VHOST_USER_SEND_RARP request to emulate a fake
RARP for guest

To do that we have to consider two kinds of guest:
  1. Guest with virtio driver implementing VIRTIO_GUEST_ANNOUNCE feature
  2. Guest with virtio driver that does not have the VIRTIO_GUEST_ANNOUNCE
feature. This is the case with old kernel or guest running a dpdk (virtio
pmd of dpdk does not have this feature)

Guest with VIRTIO_GUEST_ANNOUNCE feature sends automatically some GARP
after a migration if this feature has been negotiated. So the only thing to
do it is to negotiate the VIRTIO_GUEST_ANNOUNCE feature between QEMU, vhost
backend and the guest.
For this kind of guest the vhost-backend must announce the support of
VIRTIO_GUEST_ANNOUNCE feature. As vhost-backend has no particular action to
do in this case the support of VIRTIO_GUEST_ANNOUNCE feature can be
unconditionally set in QEMU in the future.

For guest without VIRTIO_GUEST_ANNOUNCE feature we have to send a fake
RARP: QEMU knows the MAC address of the guest and can create and broadcast
a RARP. But in case of vhost-backend QEMU is not able to broadcast this
fake RARP and must ask to the vhost backend to do it through the
VHOST_USER_SEND_RARP request. When the vhost backend receives this message
it must create a fake RARP message (as done by QEMU) and do the appropriate
operation as this message has been sent by the guest through the virtio
rings.


To solve this point 2 solutions are implemented:
 - After the migration the guest automatically sends GARP. This solution
occurs if VIRTIO_GUEST_ANNOUNCE feature has been negotiated between QEMU
and the guest.
 * VIRTIO_GUEST_ANNOUNCE

[dpdk-dev] Urgent - Fwd: [PATCH] doc: announce ABI change for link speed

[Jan Viktorin]

Matej is aware of those changes (towards 100G) and we were discussing
this extension already. Great to see that this topic is moving on.

Jan

On Tue, 15 Dec 2015 11:56:47 +0100
Viktor Pu?  wrote:

> CCing to Jan in case Matej is offline today - can you ack this?
> 
> Best,
> Viktor
> 
> > On 15 Dec 2015, at 11:42, Thomas Monjalon  
> > wrote:
> > 
> > Please, are you available to allow 100G in next DPDK release?
> > It must be accepted before releasing 2.2 (today).
> > Thanks
> > 
> > 2015-12-15 08:31, Thomas Monjalon:  
> >> Please ack ASAP to reach 3 acks before the release (in the coming hours).
> >> Thanks a lot
> >> 
> >> ---
> >> 
> >> Objet : [PATCH] doc: announce ABI change for link speed
> >> Date : mardi 15 d?cembre 2015, 08:21:14
> >> De : Thomas Monjalon 
> >> ? : dev at dpdk.org
> >> CC : Marc Sune , Olga Shern  >> mellanox.com>, Matej Vido 
> >> 
> >> A rework was prepared by Marc Sune:
> >> http://dpdk.org/ml/archives/dev/2015-October/026037.html
> >> The goal is to retrieve the supported link speed of a device
> >> and to allow 100G devices while having a consistent API.
> >> 
> >> Signed-off-by: Thomas Monjalon 
> >> ---
> >> doc/guides/rel_notes/deprecation.rst | 3 +++
> >> 1 file changed, 3 insertions(+)
> >> 
> >> diff --git a/doc/guides/rel_notes/deprecation.rst 
> >> b/doc/guides/rel_notes/deprecation.rst
> >> index a4abb08..f8a41dd 100644
> >> --- a/doc/guides/rel_notes/deprecation.rst
> >> +++ b/doc/guides/rel_notes/deprecation.rst
> >> @@ -12,6 +12,9 @@ Deprecation Notices
> >>   ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
> >>   tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
> >> 
> >> +* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
> >> +  must be updated to support 100G link and to have a cleaner link speed 
> >> API.
> >> +
> >> * ABI changes is planned for the reta field in struct 
> >> rte_eth_rss_reta_entry64
> >>   which handles at most 256 entries (8 bits) while newer NICs support 
> >> larger
> >>   tables (512 entries).
> >>   
> 



-- 
  Jan ViktorinE-mail: Viktorin at RehiveTech.com
  System ArchitectWeb:www.RehiveTech.com
  RehiveTech
  Brno, Czech Republic

[dpdk-dev] [PATCH] doc: announce ABI change for link speed

[Jan Viktorin]

On Tue, 15 Dec 2015 08:21:14 +0100
Thomas Monjalon  wrote:

> A rework was prepared by Marc Sune:
> http://dpdk.org/ml/archives/dev/2015-October/026037.html
> The goal is to retrieve the supported link speed of a device
> and to allow 100G devices while having a consistent API.
> 
> Signed-off-by: Thomas Monjalon 

Acked-by: Jan Viktorin 

[dpdk-dev] [PATCH] doc: include ixgbe rx error changes

[Harry van Haaren]

This patch updates the release notes to include the changes
made (by me), which were not appropriatly documented at the time.
Hence, this patch fixes a number of missing docs,

Fixes: e81a315e5dc5 ("ixgbe: add MAC short packet discard count to Rx errors")
Fixes: 48dd1a82a615 ("ixgbe: remove mac fault counts from Rx errors")
Fixes: 256ff05a9cae ("ixgbe: fix Rx errors statistics for UDP checksum")

Also, the CRC byte removal was not added to release notes, so
Fixes: 156c5a8cf913 ("e1000: remove CRC size from byte counters")
Fixes: c03fcee9abbd ("ixgbe: remove CRC size from byte counters")
Fixes: 0834d1524dee ("i40e: remove CRC size from byte counters")

Signed-off-by: Harry van Haaren 

---
Apologies for the oversight - I have a cheat-sheet now :)

 doc/guides/rel_notes/release_2_2.rst | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 1ad5891..bb7d15a 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -341,6 +341,8 @@ Drivers

   Assign a random MAC address in VF when not assigned by PF.

+* **igb: Removed CRC bytes from byte counter statistics.**
+
 * **ixgbe: Fixed issue with X550 DCB.**

   Fixed a DCB issue with x550 where for 8 TCs (Traffic Classes), if a packet
@@ -361,6 +363,17 @@ Drivers
   packets have to be sent. As part of that fix, ``tx_rs_thresh`` for ixgbe PMD
   is not allowed to be greater then to 32 to comply with HW restrictions.

+* **ixgbe: Fixed rx error statistic counter.**
+
+  Fixed an issue that the rx error counter of ixgbe was not accurate. The
+  mac short packet discard count (mspdc) was added to the counter. Mac local
+  faults and mac remote faults are removed as they do not count packets but
+  errors, and jabber errors were removed as they are already accounted for
+  by the CRC error counter. Finally the XEC (l3 / l4 checksum error) counter
+  was removed due to errata, see commit 256ff05a9cae for details.
+
+* **ixgbe: Removed CRC bytes from byte counter statistics.**
+
 * **i40e: Fixed base driver allocation when not using first numa node.**

   Fixed i40e issue that occurred when a DPDK application didn't initialize
@@ -382,6 +395,8 @@ Drivers
   Fixed an issue of not freeing a memzone in the call to free the memory for
   adminq DMA.

+* **i40e: Removed CRC bytes from byte counter statistics.**
+
 * **mlx: Fixed driver loading.**

   The mlx drivers were unable to load when built as a shared library,
-- 
1.9.1

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Pavel Fedin]

 Hello!

> Note quite sure. I found Thibaut submitted a patch to send
> VHOST_USER_SEND_RARP request after migration is done months
> ago. Thibaut, would you please elaborate it a bit more what
> should be done on vhost-user backend? To construct a gratuitous
> ARP request and broadcast it?

 By the way, some more info for you all.
1. I've just examined qemu_announce_self() and i see that IPs are all set to 0 
in the packet it generates. It's quite logical
because qemu has no idea what address is used by the guest, even more, 
theoretically it could be not IPv4 at all. But then - how can
it work at all, and what's the use for this packet?
2. I tried to work around if by adding VIRTIO_NET_F_GUEST_ANNOUNCE. I expected 
that the guest will see it and make announcement by
itself. But result was quite the opposite - PING stopped working at all, right 
from the beginning, even without migration.

 Can local qemu/DPDK/etc gurus give some explanation?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

[dpdk-dev] [PATCH] doc: announce ABI change for link speed

[Adrien Mazarguil]

On Tue, Dec 15, 2015 at 08:21:14AM +0100, Thomas Monjalon wrote:
> A rework was prepared by Marc Sune:
> http://dpdk.org/ml/archives/dev/2015-October/026037.html
> The goal is to retrieve the supported link speed of a device
> and to allow 100G devices while having a consistent API.
> 
> Signed-off-by: Thomas Monjalon 

Acked-by: Adrien Mazarguil 

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH] doc: improve freebsd guide layout

[John McNamara]

Fixed FreeBSD Getting Started Guide rst layout to improve
rendering in PDF.

Signed-off-by: John McNamara 
---
 doc/guides/freebsd_gsg/build_dpdk.rst | 205 --
 doc/guides/freebsd_gsg/build_sample_apps.rst  | 158 ++--
 doc/guides/freebsd_gsg/install_from_ports.rst |  67 +
 doc/guides/freebsd_gsg/intro.rst  |  22 +--
 4 files changed, 216 insertions(+), 236 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst 
b/doc/guides/freebsd_gsg/build_dpdk.rst
index 8eff599..ceacf7f 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -33,76 +33,63 @@
 Compiling the DPDK Target from Source
 =

-.. note::
-
-Testing has been performed using FreeBSD* 10.0-RELEASE (x86_64) and 
requires the
-installation of the kernel sources, which should be included during the
-installation of FreeBSD*. The DPDK also requires the use of FreeBSD*
-ports to compile and function.
-
 System Requirements
 ---

 The DPDK and its applications require the GNU make system (gmake)
-to build on FreeBSD*. Optionally, gcc may also be used in place of clang
+to build on FreeBSD. Optionally, gcc may also be used in place of clang
 to build the DPDK, in which case it too must be installed prior to
 compiling the DPDK. The installation of these tools is covered in this
 section.

 Compiling the DPDK requires the FreeBSD kernel sources, which should be
-included during the installation of FreeBSD* on the development platform.
-The DPDK also requires the use of FreeBSD* ports to compile and function.
+included during the installation of FreeBSD on the development platform.
+The DPDK also requires the use of FreeBSD ports to compile and function.

-To use the FreeBSD* ports system, it is required to update and extract the 
FreeBSD*
+To use the FreeBSD ports system, it is required to update and extract the 
FreeBSD
 ports tree by issuing the following commands:

 .. code-block:: console

-root at host:~ # portsnap fetch
-root at host:~ # portsnap extract
+portsnap fetch
+portsnap extract

 If the environment requires proxies for external communication, these can be 
set
 using:

 .. code-block:: console

-root at host:~ # setenv http_proxy :
-root at host:~ # setenv ftp_proxy :
-
-The FreeBSD* ports below need to be installed prior to building the DPDK.
-In general these can be installed using the following set of commands:
+setenv http_proxy :
+setenv ftp_proxy :

-#.  cd /usr/ports/
+The FreeBSD ports below need to be installed prior to building the DPDK.
+In general these can be installed using the following set of commands::

-#.  make config-recursive
+   cd /usr/ports/

-#.  make install
+   make config-recursive

-#.  make clean
+   make install

-Each port location can be found using:
+   make clean

-.. code-block:: console
+Each port location can be found using::

-user at host:~ # whereis 
+   whereis 

 The ports required and their locations are as follows:

-dialog4ports
-   /usr/ports/ports-mgmt/dialog4ports
+* dialog4ports: ``/usr/ports/ports-mgmt/dialog4ports``

-GNU make(gmake)
-   /usr/ports/devel/gmake
+* GNU make(gmake): ``/usr/ports/devel/gmake``

-coreutils
-   /usr/ports/sysutils/coreutils
+* coreutils: ``/usr/ports/sysutils/coreutils``

-For compiling and using the DPDK with gcc, it too must be installed
+For compiling and using the DPDK with gcc, the compiler must be installed
 from the ports collection:

-gcc: version 4.8 is recommended
-   /usr/ports/lang/gcc48
-   (Ensure that CPU_OPTS is selected (default is OFF))
+* gcc: version 4.8 is recommended ``/usr/ports/lang/gcc48``.
+  Ensure that ``CPU_OPTS`` is selected (default is OFF).

 When running the make config-recursive command, a dialog may be presented to 
the
 user. For the installation of the DPDK, the default options were used.
@@ -111,7 +98,7 @@ user. For the installation of the DPDK, the default options 
were used.

 To avoid multiple dialogs being presented to the user during make install,
 it is advisable before running the make install command to re-run the
-make config -recursive command until no more dialogs are seen.
+make config-recursive command until no more dialogs are seen.


 Install the DPDK and Browse Sources
@@ -121,10 +108,12 @@ First, uncompress the archive and move to the DPDK source 
directory:

 .. code-block:: console

-user at host:~ # unzip DPDK-zip
-user at host:~ # cd DPDK-
-user at host:~/DPDK # ls
-app/ config/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefile mk/ scripts/ 
tools/
+unzip DPDK-.zip
+cd DPDK-
+
+ls
+app/ config/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefile
+mk/ scripts/ tools/

 The DPDK is composed of several directories:

@@ -139,38 +128,36 @@ The DPDK is composed of several directories:
 Installation of the DPDK Target Environments
 --

[dpdk-dev] [PATCH 2/2] ethdev: remove old flow director symbols

[Thomas Monjalon]

The API has been removed but the symbols were still declared in the map.

Fixes: a421b86a4a02 ("ethdev: remove old flow director API")

Signed-off-by: Thomas Monjalon 
---
 lib/librte_ether/rte_ether_version.map | 8 
 1 file changed, 8 deletions(-)

diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index 17a11c7..d8db24d 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -27,14 +27,6 @@ DPDK_2.2 {
rte_eth_dev_count;
rte_eth_dev_default_mac_addr_set;
rte_eth_dev_detach;
-   rte_eth_dev_fdir_add_perfect_filter;
-   rte_eth_dev_fdir_add_signature_filter;
-   rte_eth_dev_fdir_get_infos;
-   rte_eth_dev_fdir_remove_perfect_filter;
-   rte_eth_dev_fdir_remove_signature_filter;
-   rte_eth_dev_fdir_set_masks;
-   rte_eth_dev_fdir_update_perfect_filter;
-   rte_eth_dev_fdir_update_signature_filter;
rte_eth_dev_filter_ctrl;
rte_eth_dev_filter_supported;
rte_eth_dev_flow_ctrl_get;
-- 
2.5.2

[dpdk-dev] [PATCH 1/2] eal: remove zombie symbols

[Thomas Monjalon]

test_mp_secondary was initially added by mistake.
rte_snprintf has been removed.

Fixes: 9d41beed24b0 ("lib: provide initial versioning")
Fixes: 3185322809c1 ("eal: remove rte_snprintf")

Signed-off-by: Thomas Monjalon 
---
 doc/guides/sample_app_ug/exception_path.rst   | 2 +-
 doc/guides/sample_app_ug/ip_reassembly.rst| 2 +-
 doc/guides/sample_app_ug/kernel_nic_interface.rst | 6 +++---
 doc/guides/sample_app_ug/l3_forward.rst   | 2 +-
 examples/l3fwd-power/main.c   | 4 ++--
 lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 --
 lib/librte_eal/linuxapp/eal/rte_eal_version.map   | 2 --
 7 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/doc/guides/sample_app_ug/exception_path.rst 
b/doc/guides/sample_app_ug/exception_path.rst
index 3cc7cbe..c3f8f88 100644
--- a/doc/guides/sample_app_ug/exception_path.rst
+++ b/doc/guides/sample_app_ug/exception_path.rst
@@ -173,7 +173,7 @@ The code for creating the TAP interface is as follows:
 }

 if (name)
-rte_snprintf(name, IFNAMSIZ, ifr.ifr_name);
+snprintf(name, IFNAMSIZ, ifr.ifr_name);

 return fd;
 }
diff --git a/doc/guides/sample_app_ug/ip_reassembly.rst 
b/doc/guides/sample_app_ug/ip_reassembly.rst
index 050802a..6bf5938 100644
--- a/doc/guides/sample_app_ug/ip_reassembly.rst
+++ b/doc/guides/sample_app_ug/ip_reassembly.rst
@@ -223,7 +223,7 @@ each RX queue uses its own mempool.
 nb_mbuf += RTE_TEST_RX_DESC_DEFAULT + RTE_TEST_TX_DESC_DEFAULT;
 nb_mbuf = RTE_MAX(nb_mbuf, (uint32_t)NB_MBUF);

-rte_snprintf(buf, sizeof(buf), "mbuf_pool_%u_%u", lcore, queue);
+snprintf(buf, sizeof(buf), "mbuf_pool_%u_%u", lcore, queue);

 if ((rxq->pool = rte_mempool_create(buf, nb_mbuf, MBUF_SIZE, 0, 
sizeof(struct rte_pktmbuf_pool_private), rte_pktmbuf_pool_init, NULL,
 rte_pktmbuf_init, NULL, socket, MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET)) 
== NULL) {
diff --git a/doc/guides/sample_app_ug/kernel_nic_interface.rst 
b/doc/guides/sample_app_ug/kernel_nic_interface.rst
index c8fc10a..985c664 100644
--- a/doc/guides/sample_app_ug/kernel_nic_interface.rst
+++ b/doc/guides/sample_app_ug/kernel_nic_interface.rst
@@ -265,11 +265,11 @@ The code for allocating the kernel NIC interfaces for a 
specific port is as foll

 memset(&conf, 0, sizeof(conf));
 if (params[port_id]->nb_lcore_k) {
-rte_snprintf(conf.name, RTE_KNI_NAMESIZE, "vEth%u_%u", 
port_id, i);
+snprintf(conf.name, RTE_KNI_NAMESIZE, "vEth%u_%u", port_id, i);
 conf.core_id = params[port_id]->lcore_k[i];
 conf.force_bind = 1;
 } else
-rte_snprintf(conf.name, RTE_KNI_NAMESIZE, "vEth%u", port_id);
+snprintf(conf.name, RTE_KNI_NAMESIZE, "vEth%u", port_id);
 conf.group_id = (uint16_t)port_id;
 conf.mbuf_size = MAX_PACKET_SZ;

@@ -352,7 +352,7 @@ The code is as follows:
 goto fail;
 }

-rte_snprintf(s, sizeof(s), "%.*s", size, p);
+snprintf(s, sizeof(s), "%.*s", size, p);
 nb_token = rte_strsplit(s, sizeof(s), str_fld, _NUM_FLD, ',');

 if (nb_token <= FLD_LCORE_TX) {
diff --git a/doc/guides/sample_app_ug/l3_forward.rst 
b/doc/guides/sample_app_ug/l3_forward.rst
index 34a84f1..4ce734b 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -233,7 +233,7 @@ The LPM object is created and loaded with the 
pre-configured entries read from a

 /* create the LPM table */

-rte_snprintf(s, sizeof(s), "IPV4_L3FWD_LPM_%d", socketid);
+snprintf(s, sizeof(s), "IPV4_L3FWD_LPM_%d", socketid);

 ipv4_l3fwd_lookup_struct[socketid] = rte_lpm_create(s, socketid, 
IPV4_L3FWD_LPM_MAX_RULES, 0);

diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 9175989..828c18a 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -1373,7 +1373,7 @@ setup_hash(int socketid)
char s[64];

/* create ipv4 hash */
-   rte_snprintf(s, sizeof(s), "ipv4_l3fwd_hash_%d", socketid);
+   snprintf(s, sizeof(s), "ipv4_l3fwd_hash_%d", socketid);
ipv4_l3fwd_hash_params.name = s;
ipv4_l3fwd_hash_params.socket_id = socketid;
ipv4_l3fwd_lookup_struct[socketid] =
@@ -1383,7 +1383,7 @@ setup_hash(int socketid)
"socket %d\n", socketid);

/* create ipv6 hash */
-   rte_snprintf(s, sizeof(s), "ipv6_l3fwd_hash_%d", socketid);
+   snprintf(s, sizeof(s), "ipv6_l3fwd_hash_%d", socketid);
ipv6_l3fwd_hash_params.name = s;
ipv6_l3fwd_hash_params.socket_id = socketid;
ipv6_l3fwd_lookup_struct[socketid] =
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 7a88387..9d7adf1 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++

[dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support

[Pavel Fedin]

 Hello!

> I mean I do find that qemu_annouce_self composes an ARP
> broadcoast request, but it seems that I didn't catch it on
> the target host.
> 
> Something wrong, or someting I missed?

 To tell the truth, i don't know. I am also learning qemu internals on the fly. 
Indeed, i see that it should announce itself. But
this brings up a question: why do we need special announce procedure in 
vhost-user then?
 I think you can add some debug output and see how it works in realtime. This 
is what i normally do when i don't understand in which
sequence things happen.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

[dpdk-dev] [PATCH] doc: cleanup doc index files

[Thomas Monjalon]

2015-12-15 10:36, Van Haaren, Harry:
> > Subject: [dpdk-dev] [PATCH] doc: cleanup doc index files
> > 
> > Remove **Contents** and |Today| from the rst doc index files since
> > these are already added automatically to PDF files and are of
> > little value to the Html files where the Contents is shown in a
> > sidebar.
> > 
> > Signed-off-by: John McNamara 
> 
> Acked-by: Harry van Haaren 

Applied, thanks

[dpdk-dev] [PATCH] doc: fix minor rst doc issues

[Thomas Monjalon]

2015-12-15 10:29, Van Haaren, Harry:
> > Subject: [dpdk-dev] [PATCH] doc: fix minor rst doc issues
> > 
> > Fix minor rst doc issues in the contributing/design.rst doc to correct
> > rendering of notes and code blocks.
> > 
> > Signed-off-by: John McNamara 
> > ---
> >  doc/guides/contributing/design.rst | 37 
> > +++--
> >  1 file changed, 19 insertions(+), 18 deletions(-)
> 
> Acked-by: Harry van Haaren 

Applied, thanks

[dpdk-dev] [PATCH] doc: fix spellings in docs

[Thomas Monjalon]

2015-12-15 10:18, Van Haaren, Harry:
> > Subject: [dpdk-dev] [PATCH] doc: fix spellings in docs
> > 
> > Fix various spellings in rst docs.
> > 
> > Signed-off-by: John McNamara 
> 
> Acked-by: Harry van Haaren 

Applied, thanks

[dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# Successfully setup DPDK OVS with vhostuser

[Abhijeet Karve]

Dear All,

After seting up system boot parameters as shown below, the issue is 
resolved now & we are able to successfully setup openvswitch netdev-dpdk 
with vhostuser support.

_
Setup 2 sets of huge pages with different sizes. One for Vhost and another 
for Guest VM.
 Edit /etc/default/grub.
GRUB_CMDLINE_LINUX="iommu=pt intel_iommu=on  hugepagesz=1G 
hugepages=10 hugepagesz=2M hugepages=4096"
 # update-grub
   - Mount the huge pages into different directory.
  # sudo mount -t hugetlbfs nodev /mnt/huge_2M -o pagesize=2M
  # sudo mount -t hugetlbfs nodev /mnt/huge_1G -o pagesize=1G
_

At present we are facing an issue in Testing DPDK application on setup. In 
our scenario, We have DPDK instance launched on top of the Openstack Kilo 
compute node. Not able to assign DHCP IP from controller. 


Thanks & Regards
Abhijeet Karve

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

[dpdk-dev] VFIO no-iommu

[Alejandro Lucero]

Hi,

I know a bit about VFIO implementation, have been debugging IOMMU (intel)
problems,  know how QEMU/KVM work about using legacy or vfio attached
devices, and I'm the maintainer of a DPDK PMD recently accepted upstream
which requires our particular UIO driver (not maintained upstream). So I
guess I could help with this effort and testing the code with our card. Of
course, I can not be full time on this but I will be happy to contribute.


On Fri, Dec 11, 2015 at 11:20 PM, Jan Viktorin 
wrote:

> Hello,
>
> I am not involved in the vfio very much, however, I was watching some
> vfio-related code in last few weeks. It looks promising to me and
> IMHO it seems to the best way to bring a support of integrated Ethernet
> MACs into DPDK (related to many SoCs). Unfortunately, the ARMv7 SoCs (I
> know) lacks of an IOMMU... The only protection there is the TrustZone
> technology but I have no idea of its support in the kernel. It's also
> far from being a replacement of an IOMMU. When using FPGAs, it is
> possible to put an IOMMU engine there (I've got such a prototype
> somewhere in my VHDL library) but nobody will probably do use because
> of saving on-chip resources.
>
> The X-Gene SoC (ARM 64) contains 2x 10 Gbps EMACs on the chip. I have no
> idea about IOMMUs there. Thus, this platform can probably benefit of
> such driver as well. The question is whether there is some interest to
> have this kind of support in DPDK.
>
> Thus, I'd like to have the vfio/no-iommu to support the ARMv7 (otherwise
> it would be effectively dead in DPDK). Unfortunately, it's not my
> primary job at the moment.
>
> Regards
> Jan
>
> Note: as far as I know, it is discouraged to refer to lkml.org as
> it is often very slow - my case today :).
>
> On Fri, 11 Dec 2015 17:28:43 +0100
> Thomas Monjalon  wrote:
>
> > Recently there were some discussions to have an upstream replacement
> > for our igb_uio module.
> > Several solutions were discussed (new uio driver, uio_pci_generic, vfio):
> >   https://lkml.org/lkml/2015/10/16/700
> >
> > Alex Williamson (maintainer of VFIO driver), submitted a solution
> > and was waiting some feedback. Unfortunately, nobody caught it and
> > he has reverted his work:
> >
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ae5515d
> >
> > It is an important challenge to remove our out-of-tree modules and
> > especially igb_uio. It is a long way to have a standard solution
> integrated
> > in every distributions.
> > The current cooking Linux kernel is 4.4 and will have a long term
> maintenance:
> >   https://kernel.org/releases.html
> > So it is a pity to miss this opportunity.
> >
> > Stephen has fixed a bug to use the IOMMU group zero:
> >   http://dpdk.org/browse/dpdk/commit/?id=22215f141b1
> >
> > Is there someone interested to work on VFIO no-iommu and provide
> > some feedbacks?
> > We also need to prepare a documentation patch to explain its usage
> > compared to the standard VFIO mode.
> >
> > Thanks
>
>

[dpdk-dev] [PATCH] doc: remove unused references from faq

[John McNamara]

The faq refers to Linux*, with an asterisk, without any equivalent
note or footnote. This is a legacy from older versions of the docs.
This update removes it.

Signed-off-by: John McNamara 
---
 doc/guides/faq/faq.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/guides/faq/faq.rst b/doc/guides/faq/faq.rst
index d58673b..368374f 100644
--- a/doc/guides/faq/faq.rst
+++ b/doc/guides/faq/faq.rst
@@ -157,13 +157,13 @@ I am getting errors about not being able to open files. 
Why?

 As the DPDK operates, it opens a lot of files, which can result in reaching 
the open files limits, which is set using the ulimit command or in the 
limits.conf file.
 This is especially true when using a large number (>512) of 2 MB huge pages. 
Please increase the open file limit if your application is not able to open 
files.
-This can be done either by issuing a ulimit command or editing the limits.conf 
file. Please consult Linux* manpages for usage information.
+This can be done either by issuing a ulimit command or editing the limits.conf 
file. Please consult Linux manpages for usage information.


 VF driver for IXGBE devices cannot be initialized
 -

-Some versions of Linux* IXGBE driver do not assign a random MAC address to VF 
devices at initialization.
+Some versions of Linux IXGBE driver do not assign a random MAC address to VF 
devices at initialization.
 In this case, this has to be done manually on the VM host, using the following 
command:

 .. code-block:: console
@@ -195,10 +195,10 @@ When trying to send packets from an application to 
itself, meaning smac==dmac, u
 Check on register ``LLE(PFVMTXSSW[n])``, which allows an individual pool to 
send traffic and have it looped back to itself.


-Can I split packet RX to use DPDK and have an application's higher order 
functions continue using Linux* pthread?
--
+Can I split packet RX to use DPDK and have an application's higher order 
functions continue using Linux pthread?
+

-The DPDK's lcore threads are Linux* pthreads bound onto specific cores. 
Configure the DPDK to do work on the same
+The DPDK's lcore threads are Linux pthreads bound onto specific cores. 
Configure the DPDK to do work on the same
 cores and run the application's other work on other cores using the DPDK's 
"coremask" setting to specify which
 cores it should launch itself on.

-- 
2.5.0

[dpdk-dev] [PATCH 3/3] driver/net/mpipe: fix a mpipe link initialization ordering issue

[Liming Sun]

Mpipe link structure is initialized in function mpipe_link_init().
Currently it's only called from the eth_dev_ops.dev_start, which
caused crashes when link mgmt APIs (like promiscuous_enable)
was called before eth_dev_ops.dev_start(). This submit fixed it
by calling mpipe_link_init() in rte_pmd_mpipe_devinit().

Signed-off-by: Liming Sun 
---
 drivers/net/mpipe/mpipe_tilegx.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index be7b6f2..5845511 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -752,13 +752,6 @@ mpipe_init(struct mpipe_dev_priv *priv)
if (priv->initialized)
return 0;

-   rc = mpipe_link_init(priv);
-   if (rc < 0) {
-   RTE_LOG(ERR, PMD, "%s: Failed to init link.\n",
-   mpipe_name(priv));
-   return rc;
-   }
-
rc = mpipe_recv_init(priv);
if (rc < 0) {
RTE_LOG(ERR, PMD, "%s: Failed to init rx.\n",
@@ -1633,6 +1626,13 @@ rte_pmd_mpipe_devinit(const char *ifname,
eth_dev->rx_pkt_burst = &mpipe_recv_pkts;
eth_dev->tx_pkt_burst = &mpipe_xmit_pkts;

+   rc = mpipe_link_init(priv);
+   if (rc < 0) {
+   RTE_LOG(ERR, PMD, "%s: Failed to init link.\n",
+   mpipe_name(priv));
+   return rc;
+   }
+
return 0;
 }

-- 
1.7.1

[dpdk-dev] [PATCH 2/3] driver/net/mpipe: optimize mpipe buffer return mechanism.

[Liming Sun]

This submit has changes to optimize the mpipe buffer return. When
a packet is received, instead of allocating and refilling the
buffer stack right away, it tracks the number of pending buffers,
and use HW buffer return as an optimization when the pending
number is below certain threshold, thus save two MMIO writes and
improves performance especially for bidirectional traffic case.

Signed-off-by: Liming Sun 
---
 drivers/net/mpipe/mpipe_tilegx.c |   50 ++---
 1 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index 35134ba..be7b6f2 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -78,6 +78,13 @@ struct mpipe_context {
struct mpipe_channel_config channels[MPIPE_MAX_CHANNELS];
 };

+/* Per-core local data. */
+struct mpipe_local {
+   int mbuf_push_debt[RTE_MAX_ETHPORTS];   /* Buffer push debt. */
+} __rte_cache_aligned;
+
+#define MPIPE_BUF_DEBT_THRESHOLD   32
+static __thread struct mpipe_local mpipe_local;
 static struct mpipe_context mpipe_contexts[GXIO_MPIPE_INSTANCE_MAX];
 static int mpipe_instances;
 static const char *drivername = "MPIPE PMD";
@@ -137,7 +144,7 @@ struct mpipe_dev_priv {
int first_bucket;   /* mPIPE bucket start index. */
int first_ring; /* mPIPE notif ring start index. */
int notif_group;/* mPIPE notif group. */
-   rte_atomic32_t dp_count;/* Active datapath thread count. */
+   rte_atomic32_t dp_count __rte_cache_aligned;/* DP Entry count. */
int tx_stat_mapping[RTE_ETHDEV_QUEUE_STAT_CNTRS];
int rx_stat_mapping[RTE_ETHDEV_QUEUE_STAT_CNTRS];
 };
@@ -461,6 +468,14 @@ mpipe_dp_wait(struct mpipe_dev_priv *priv)
}
 }

+static inline int
+mpipe_mbuf_stack_index(struct mpipe_dev_priv *priv, struct rte_mbuf *mbuf)
+{
+   return (mbuf->port < RTE_MAX_ETHPORTS)?
+   mpipe_priv(&rte_eth_devices[mbuf->port])->stack :
+   priv->stack;
+}
+
 static inline struct rte_mbuf *
 mpipe_recv_mbuf(struct mpipe_dev_priv *priv, gxio_mpipe_idesc_t *idesc,
int in_port)
@@ -1267,6 +1282,7 @@ mpipe_do_xmit(struct mpipe_tx_queue *tx_queue, struct 
rte_mbuf **tx_pkts,
unsigned nb_bytes = 0;
unsigned nb_sent = 0;
int nb_slots, i;
+   uint8_t port_id;

PMD_DEBUG_TX("Trying to transmit %d packets on %s:%d.\n",
 nb_pkts, mpipe_name(tx_queue->q.priv),
@@ -1315,14 +1331,23 @@ mpipe_do_xmit(struct mpipe_tx_queue *tx_queue, struct 
rte_mbuf **tx_pkts,
if (priv->tx_comps[idx])
rte_pktmbuf_free_seg(priv->tx_comps[idx]);

+   port_id = (mbuf->port < RTE_MAX_ETHPORTS)?
+   mbuf->port : priv->port_id;
desc = (gxio_mpipe_edesc_t) { {
.va= rte_pktmbuf_mtod(mbuf, uintptr_t),
.xfer_size = rte_pktmbuf_data_len(mbuf),
.bound = next ? 0 : 1,
+   .stack_idx = mpipe_mbuf_stack_index(priv, mbuf),
} };
+   if (mpipe_local.mbuf_push_debt[port_id] > 0) {
+   mpipe_local.mbuf_push_debt[port_id]--;
+   desc.hwb = 1;
+   priv->tx_comps[idx] = NULL;
+   }
+   else
+   priv->tx_comps[idx] = mbuf;

nb_bytes += mbuf->data_len;
-   priv->tx_comps[idx] = mbuf;
gxio_mpipe_equeue_put_at(equeue, desc, slot + i);

PMD_DEBUG_TX("%s:%d: Sending packet %p, len %d\n",
@@ -1443,17 +1468,22 @@ mpipe_do_recv(struct mpipe_rx_queue *rx_queue, struct 
rte_mbuf **rx_pkts,
continue;
}

-   mbuf = __rte_mbuf_raw_alloc(priv->rx_mpool);
-   if (unlikely(!mbuf)) {
-   nb_nomem++;
-   gxio_mpipe_iqueue_drop(iqueue, idesc);
-   PMD_DEBUG_RX("%s:%d: RX alloc failure\n",
+   if (mpipe_local.mbuf_push_debt[in_port] <
+   MPIPE_BUF_DEBT_THRESHOLD)
+   mpipe_local.mbuf_push_debt[in_port]++;
+   else {
+   mbuf = __rte_mbuf_raw_alloc(priv->rx_mpool);
+   if (unlikely(!mbuf)) {
+   nb_nomem++;
+   gxio_mpipe_iqueue_drop(iqueue, idesc);
+   PMD_DEBUG_RX("%s:%d: alloc failure\n",
   

[dpdk-dev] [PATCH 1/3] driver/net/mpipe: support native build on tilegx platform.

[Liming Sun]

This submit updates the CROSS setting to support native build on
TileGx platform. It also enable the combined library by default.

Signed-off-by: Liming Sun 
---
 MAINTAINERS   |3 ++-
 config/defconfig_tile-tilegx-linuxapp-gcc |4 
 mk/arch/tile/rte.vars.mk  |6 ++
 3 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3292e84..8f7e9ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,8 +138,9 @@ M: Jianbo Liu 
 F: lib/librte_eal/common/include/arch/arm/*_64.h
 F: lib/librte_acl/acl_run_neon.*

-EZchip TILE-Gx
+EZchip TILE-Gx/Mx
 M: Zhigang Lu 
+M: Liming Sun 
 F: lib/librte_eal/common/include/arch/tile/
 F: drivers/net/mpipe/

diff --git a/config/defconfig_tile-tilegx-linuxapp-gcc 
b/config/defconfig_tile-tilegx-linuxapp-gcc
index 9df9d7f..fb61bcd 100644
--- a/config/defconfig_tile-tilegx-linuxapp-gcc
+++ b/config/defconfig_tile-tilegx-linuxapp-gcc
@@ -70,3 +70,7 @@ CONFIG_RTE_LIBRTE_SCHED=n
 CONFIG_RTE_LIBRTE_PORT=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_LIBRTE_CXGBE_PMD=n
+
+# Compile combined lib by default.
+CONFIG_RTE_BUILD_COMBINE_LIBS=y
diff --git a/mk/arch/tile/rte.vars.mk b/mk/arch/tile/rte.vars.mk
index b518986..06dab18 100644
--- a/mk/arch/tile/rte.vars.mk
+++ b/mk/arch/tile/rte.vars.mk
@@ -30,7 +30,13 @@


 ARCH  ?= tile
+
+HOST_ARCH := ${shell uname -m}
+ifneq ($(filter tile%,${HOST_ARCH}),)
+CROSS =
+else
 CROSS ?= tile-
+endif

 CPU_CFLAGS  ?=
 CPU_LDFLAGS ?=
-- 
1.7.1

[dpdk-dev] [PATCH 0/3] Some misc fixes and optimization for the mpipe driver

[Liming Sun]

This patch serie includes some fixes/enhancements to the mpipe driver.
1. Support native build on the TileGx platform;
   Previously only cross build was supported.

2. Optimize the mpipe buffer return mechanism by introducing a return
   pending counter and doing HW buffer return if pssible.

3. Move the mpipe link initialization to an earlier place to support
   link management APIs.

Liming Sun (3):
  driver/net/mpipe: support native build on tilegx platform.
  driver/net/mpipe: optimize mpipe buffer return mechanism.
  driver/net/mpipe: fix a mpipe link initialization ordering issue

 MAINTAINERS   |3 +-
 config/defconfig_tile-tilegx-linuxapp-gcc |4 ++
 drivers/net/mpipe/mpipe_tilegx.c  |   64 +
 mk/arch/tile/rte.vars.mk  |6 +++
 4 files changed, 59 insertions(+), 18 deletions(-)

[dpdk-dev] [PATCH] doc: cleanup doc index files

[Van Haaren, Harry]

> Subject: [dpdk-dev] [PATCH] doc: cleanup doc index files
> 
> Remove **Contents** and |Today| from the rst doc index files since
> these are already added automatically to PDF files and are of
> little value to the Html files where the Contents is shown in a
> sidebar.
> 
> Signed-off-by: John McNamara 
> ---
>  doc/guides/faq/index.rst| 2 --
>  doc/guides/freebsd_gsg/index.rst| 4 
>  doc/guides/index.rst| 2 --
>  doc/guides/linux_gsg/index.rst  | 4 
>  doc/guides/nics/index.rst   | 5 -
>  doc/guides/prog_guide/index.rst | 5 -
>  doc/guides/rel_notes/index.rst  | 4 
>  doc/guides/sample_app_ug/index.rst  | 4 
>  doc/guides/testpmd_app_ug/index.rst | 4 
>  doc/guides/xen/index.rst| 4 
>  10 files changed, 38 deletions(-)

Acked-by: Harry van Haaren 

[dpdk-dev] [PATCH] doc: fix minor rst doc issues

[Van Haaren, Harry]

> Subject: [dpdk-dev] [PATCH] doc: fix minor rst doc issues
> 
> Fix minor rst doc issues in the contributing/design.rst doc to correct
> rendering of notes and code blocks.
> 
> Signed-off-by: John McNamara 
> ---
>  doc/guides/contributing/design.rst | 37 +++--
>  1 file changed, 19 insertions(+), 18 deletions(-)

Acked-by: Harry van Haaren 

[dpdk-dev] [PATCH] doc: fix spellings in docs

[Van Haaren, Harry]

> Subject: [dpdk-dev] [PATCH] doc: fix spellings in docs
> 
> Fix various spellings in rst docs.
> 
> Signed-off-by: John McNamara 
> ---
>  doc/guides/contributing/coding_style.rst |  2 +-
>  doc/guides/contributing/versioning.rst   |  2 +-
>  doc/guides/cryptodevs/aesni_mb.rst   |  2 +-
>  doc/guides/nics/bnx2x.rst|  6 +++---
>  doc/guides/nics/nfp.rst  |  2 +-
>  doc/guides/nics/szedata2.rst |  4 ++--
>  doc/guides/prog_guide/env_abstraction_layer.rst  |  2 +-
>  doc/guides/prog_guide/hash_lib.rst   |  2 +-
>  doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst |  2 +-
>  doc/guides/prog_guide/overview.rst   |  2 +-
>  doc/guides/prog_guide/packet_framework.rst   | 12 ++--
>  doc/guides/rel_notes/release_1_8.rst |  2 +-
>  doc/guides/sample_app_ug/performance_thread.rst  |  2 +-
>  doc/guides/sample_app_ug/tep_termination.rst |  2 +-
>  doc/guides/sample_app_ug/test_pipeline.rst   |  6 +++---
>  15 files changed, 25 insertions(+), 25 deletions(-)

Acked-by: Harry van Haaren 

[dpdk-dev] [PATCH] doc: cleanup doc index files

[John McNamara]

Remove **Contents** and |Today| from the rst doc index files since
these are already added automatically to PDF files and are of
little value to the Html files where the Contents is shown in a
sidebar.

Signed-off-by: John McNamara 
---
 doc/guides/faq/index.rst| 2 --
 doc/guides/freebsd_gsg/index.rst| 4 
 doc/guides/index.rst| 2 --
 doc/guides/linux_gsg/index.rst  | 4 
 doc/guides/nics/index.rst   | 5 -
 doc/guides/prog_guide/index.rst | 5 -
 doc/guides/rel_notes/index.rst  | 4 
 doc/guides/sample_app_ug/index.rst  | 4 
 doc/guides/testpmd_app_ug/index.rst | 4 
 doc/guides/xen/index.rst| 4 
 10 files changed, 38 deletions(-)

diff --git a/doc/guides/faq/index.rst b/doc/guides/faq/index.rst
index 5bc84ac..6ca659f 100644
--- a/doc/guides/faq/index.rst
+++ b/doc/guides/faq/index.rst
@@ -33,8 +33,6 @@ DPDK FAQ

 This document contains some Frequently Asked Questions that arise when working 
with DPDK.

-Contents
-
 .. toctree::
 :maxdepth: 2
 :numbered:
diff --git a/doc/guides/freebsd_gsg/index.rst b/doc/guides/freebsd_gsg/index.rst
index 37e4cc1..3729f16 100644
--- a/doc/guides/freebsd_gsg/index.rst
+++ b/doc/guides/freebsd_gsg/index.rst
@@ -33,10 +33,6 @@
 Getting Started Guide for FreeBSD
 =

-|today|
-
-**Contents**
-
 .. toctree::
 :maxdepth: 2
 :numbered:
diff --git a/doc/guides/index.rst b/doc/guides/index.rst
index c5d7a9f..638eab9 100644
--- a/doc/guides/index.rst
+++ b/doc/guides/index.rst
@@ -31,8 +31,6 @@
 DPDK documentation
 ==

-Contents:
-
 .. toctree::
:maxdepth: 1
:titlesonly:
diff --git a/doc/guides/linux_gsg/index.rst b/doc/guides/linux_gsg/index.rst
index d68135b..3d3ada1 100644
--- a/doc/guides/linux_gsg/index.rst
+++ b/doc/guides/linux_gsg/index.rst
@@ -33,10 +33,6 @@
 Getting Started Guide for Linux
 ===

-|today|
-
-Contents
-
 .. toctree::
 :maxdepth: 2
 :numbered:
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 2f7506c..33c9cea 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -31,11 +31,6 @@
 Network Interface Controller Drivers
 

-|today|
-
-
-**Contents**
-
 .. toctree::
 :maxdepth: 3
 :numbered:
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index 176f2c2..9359f2e 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -31,11 +31,6 @@
 Programmer's Guide
 ==

-|today|
-
-
-**Contents**
-
 .. toctree::
 :maxdepth: 3
 :numbered:
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index d8cadeb..5c1c8c6 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -31,10 +31,6 @@
 DPDK Release Notes
 ==

-|today|
-
-Contents
-
 .. toctree::
 :maxdepth: 1
 :numbered:
diff --git a/doc/guides/sample_app_ug/index.rst 
b/doc/guides/sample_app_ug/index.rst
index becd682..8a646dd 100644
--- a/doc/guides/sample_app_ug/index.rst
+++ b/doc/guides/sample_app_ug/index.rst
@@ -31,10 +31,6 @@
 Sample Applications User Guide
 ==

-|today|
-
-**Contents**
-
 .. toctree::
 :maxdepth: 2
 :numbered:
diff --git a/doc/guides/testpmd_app_ug/index.rst 
b/doc/guides/testpmd_app_ug/index.rst
index 3b163c1..1c39a17 100644
--- a/doc/guides/testpmd_app_ug/index.rst
+++ b/doc/guides/testpmd_app_ug/index.rst
@@ -31,10 +31,6 @@
 Testpmd Application User Guide
 ==

-|today|
-
-**Contents**
-
 .. toctree::
 :maxdepth: 3
 :numbered:
diff --git a/doc/guides/xen/index.rst b/doc/guides/xen/index.rst
index 628ecc3..cb43cd2 100644
--- a/doc/guides/xen/index.rst
+++ b/doc/guides/xen/index.rst
@@ -31,10 +31,6 @@
 Xen Guide
 =

-|today|
-
-**Contents**
-
 .. toctree::
 :maxdepth: 2
 :numbered:
-- 
2.5.0

[dpdk-dev] [PATCH] doc: fix minor rst doc issues

[John McNamara]

Fix minor rst doc issues in the contributing/design.rst doc to correct
rendering of notes and code blocks.

Signed-off-by: John McNamara 
---
 doc/guides/contributing/design.rst | 37 +++--
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/doc/guides/contributing/design.rst 
b/doc/guides/contributing/design.rst
index 04803ca..bac3d1b 100644
--- a/doc/guides/contributing/design.rst
+++ b/doc/guides/contributing/design.rst
@@ -13,45 +13,46 @@ A file located in a subdir of "linuxapp" is specific to 
this execution environme

 .. note::

-   Code in DPDK libraries and applications should be generic.
-   The correct location for architecture or executive environment specific 
code is in the EAL.
+   Code in DPDK libraries and applications should be generic.
+   The correct location for architecture or executive environment specific 
code is in the EAL.

 When absolutely necessary, there are several ways to handle specific code:

 * Use a ``#ifdef`` with the CONFIG option in the C code.
   This can be done when the differences are small and they can be embedded in 
the same C file:

-.. code-block: console
+  .. code-block:: c

-   #ifdef RTE_ARCH_I686
-   toto();
-   #else
-   titi();
-   #endif
+ #ifdef RTE_ARCH_I686
+ toto();
+ #else
+ titi();
+ #endif

 * Use the CONFIG option in the Makefile. This is done when the differences are 
more significant.
-  In this case, the code is split into two separate files that are 
architecture or environment specific.  This should only apply inside the EAL 
library.
+  In this case, the code is split into two separate files that are 
architecture or environment specific.
+  This should only apply inside the EAL library.

-.. note:
+.. note::

-   As in the linux kernel, the "CONFIG_" prefix is not used in C code.
-   This is only needed in Makefiles or shell scripts.
+   As in the linux kernel, the ``CONFIG_`` prefix is not used in C code.
+   This is only needed in Makefiles or shell scripts.

 Per Architecture Sources
 

 The following config options can be used:

-* CONFIG_RTE_ARCH is a string that contains the name of the architecture.
-* CONFIG_RTE_ARCH_I686, CONFIG_RTE_ARCH_X86_64, CONFIG_RTE_ARCH_X86_64_32 or 
CONFIG_RTE_ARCH_PPC_64 are defined only if we are building for those 
architectures.
+* ``CONFIG_RTE_ARCH`` is a string that contains the name of the architecture.
+* ``CONFIG_RTE_ARCH_I686``, ``CONFIG_RTE_ARCH_X86_64``, 
``CONFIG_RTE_ARCH_X86_64_32`` or ``CONFIG_RTE_ARCH_PPC_64`` are defined only if 
we are building for those architectures.

 Per Execution Environment Sources
 ~

 The following config options can be used:

-* CONFIG_RTE_EXEC_ENV is a string that contains the name of the executive 
environment.
-* CONFIG_RTE_EXEC_ENV_BSDAPP or CONFIG_RTE_EXEC_ENV_LINUXAPP are defined only 
if we are building for this execution environment.
+* ``CONFIG_RTE_EXEC_ENV`` is a string that contains the name of the executive 
environment.
+* ``CONFIG_RTE_EXEC_ENV_BSDAPP`` or ``CONFIG_RTE_EXEC_ENV_LINUXAPP`` are 
defined only if we are building for this execution environment.

 Library Statistics
 --
@@ -77,8 +78,8 @@ are collected for any instance of any object type provided by 
the library:

 .. code-block:: console

-   # DPDK file config/common_linuxapp, config/common_bsdapp, etc.
-   CONFIG_RTE__STATS_COLLECT=y/n
+   # DPDK file config/common_linuxapp, config/common_bsdapp, etc.
+   CONFIG_RTE__STATS_COLLECT=y/n

 The default value for this DPDK configuration file variable (either "yes" or
 "no") is decided by each library.
-- 
2.5.0

[dpdk-dev] [RFC 3/3] doc: announce ABI change for filtering support

[Thomas Monjalon]

2015-12-15 14:10, Rahul Lakkireddy:
> Hi Thomas,
> 
> I am preparing a v2 of this series where I will be accomodating some
> more fields to be considered for filtering. However, if the overall
> approach seems ok to everyone then, should I submit a separate patch
> for this ABI change announcement ?

Yes, if this announce is not enough:
http://dpdk.org/browse/dpdk/commit/?id=648e6b3815a35

[dpdk-dev] VFIO no-iommu

[Alex Williamson]

On Tue, 2015-12-15 at 13:43 +, O'Driscoll, Tim wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex
> > Williamson
> > Sent: Friday, December 11, 2015 11:03 PM
> > To: Vincent JARDIN; dev at dpdk.org
> > Subject: Re: [dpdk-dev] VFIO no-iommu
> > 
> > On Fri, 2015-12-11 at 23:12 +0100, Vincent JARDIN wrote:
> > > Thanks Thomas for putting back this topic.
> > > 
> > > Alex,
> > > 
> > > I'd like to hear more about the impacts of "unsupported":
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/c
> > > ommi
> > > t/?id=033291eccbdb1b70ffc02641edae19ac825dc75d
> > > ???Use of this mode, specifically binding a device without a
> > > native
> > > ???IOMMU group to a VFIO bus driver will taint the kernel and
> > > should
> > > ???therefore not be considered supported.
> > > 
> > > It means that we get ride of uio; so it is a nice code cleanup:
> > > but
> > > why
> > > would VFIO/NO IOMMU be better if the bottomline is "unsupported"?
> > 
> > How supportable do you think the uio method is? ?Fundamentally we
> > have
> > a userspace driver doing unrestricted DMA; it can access and modify
> > any
> > memory in the system. ?This is the reason uio won't provide a
> > mechanism
> > to enable MSI and if you ask the uio maintainer, they don't support
> > DMA
> > at all, it's only intended as a programmed IO interface to the
> > device.
> > ?Unless we can sandbox a user owned device within an IOMMU
> > protected
> > container, it's not supportable. ?The VFIO no-iommu mode can simply
> > provide you that unsupported mode more easily since it leverages
> > code
> > from the supported mode, which is IOMMU protected. ?Thanks,
> 
> Thanks for clarifying.
> 
> This does seem like it would be useful for DPDK. We're doing some
> further investigation to see if it works out of the box with DPDK or
> if we need to make any changes to support it.

The iommu model is different, there's no type1 interface available when
using this mode since we have no ability to provide translation. ?The
no-iommu iommu model really does nothing, which is a possible issue for
userspace. ?Is it sufficient? ?We stopped short of creating a page
pinning interface through the no-iommu model because it requires code
and adding piles of new code for an interface we claim is unsupported
doesn't make a lot of sense. ?The device interface should be identical
to existing vfio support.

> Thomas highlighted that your original commit for this had been
> reverted. What specifically would you need from us in order to re-
> submit the VFIO No-IOMMU support?

No API changes should ever go into the kernel without being validated
by a user. ?Without that we're risking that the kernel interface is
broken and we're stuck supporting it. ?In this case I tried to make
sure we had a working user before it went it, gambled that it was close
enough to put in anyway, then paid the price when development went
silent on the user side. ?To get it back in, I'm going to need a
working use first. ?You can re-apply 033291eccbdb or re-
revert?ae5515d66362 for development of that. ?I need to see that it
works and that there's some consensus from the dpdk community that it's
a worthwhile path forward for cases without an iommu. ?There's no point
in merging it if it only becomes a userspace proof of concept. ?Thanks,

Alex

[dpdk-dev] [PATCH v3] doc: announce ABI change for struct rte_eth_conf

[Ivan Boule]

On 12/14/2015 08:48 AM, Jijiang Liu wrote:
> In current codes, tunnel configuration information is not stored in a device 
> configuration, and it will get nothing if application want to retrieve tunnel 
> config, so I think it is necessary to add rte_eth_dev_tunnel_configure() 
> function is to do the configurations including flow and classification 
> information and store it in a device configuration.
>
> And tunneling packet encapsulation operation will benifit from the change.
>
> There are more descriptions for the ABI changes below,
>
> The struct 'rte_eth_tunnel_conf' is a new, its defination like below,
> struct rte_eth_tunnel_conf {
> uint16_t tx_queue;
> uint16_t filter_type;
> struct rte_eth_tunnel_flow flow_tnl;
> };
>
> The ABI change announcement of struct 'rte_eth_tunnel_flow' have already sent 
> out, refer to [1].
>
> [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html.
>
> The change of struct 'rte_eth_conf' like below, but it have not finalized yet.
> struct rte_eth_conf {
>   ...
>   uint32_t dcb_capability_en;
>   struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */
>   struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */
>   struct rte_eth_tunnel_conf *tunnel_conf[RTE_MAX_QUEUES_PER_PORT];
>   /**< Tunnel configuration. */
> };
>
> v2 change:
>Add more description for the change.
>
> v3 change:
>Change ABI announcement description.
>
> Signed-off-by: Jijiang Liu 
> ---cmdline.c
>   doc/guides/rel_notes/deprecation.rst |6 ++
>   1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index 5c458f2..9dbe89e 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -23,3 +23,9 @@ Deprecation Notices
>   * ABI changes are planned for struct rte_eth_tunnel_flow in order to extend 
> new fileds to support
> tunneling packet configuration in unified tunneling APIs. The release 2.2 
> does not contain these ABI
> changes, but release 2.3 will, and no backwards compatibility is planned.
> +
> +* ABI changes are planned for the struct rte_eth_conf in order to add 
> 'tunnel_conf' variable
> +  in the struct to store tunnel configuration when using new API 
> rte_eth_dev_tunnel_configure
> +  (uint8_t port_id, uint16_t rx_queue, struct rte_eth_tunnel_conf * 
> tunnel_conf) to configure
> +  tunnel flow and classification information. The release 2.2 does not 
> contain these ABI change,
> +  but release 2.3 will, and no backward compatibility is planned.
>
Hi Jijiang,

Can you provide a real use case - I mean an example of a real network 
application - that really needs to save tunnel configurations in a data 
structure associated with a NIC port?

Firstly, if the only usage is to enable applications to retrieve tunnel
configurations, then you are simply growing the size of the per-port
structure with tunnel configurations, and imposing it to every DPDK 
application.
You impose it to those applications that don't care about tunneling, but 
also to those applications which do care, but which prefer to have their 
own representation of ports where they store everything they need to.

If the tunnel configuration is also used for other purposes, then it
must be precisely described what happens with the saved tunnel 
configuration when the application changes the state of a port.
This is the case for instance when the application reconfigures the 
number of RX queues of a port.
Who is responsible for checking that some tunnels won't be matched anymore?
Who is responsible for dropping/invalidating the saved tunnel 
configuration, if such operations must be performed?
This list is likely to be not exhaustive, of course.

More globally, all side-effects of saving the tunnel configuration must 
be considered and addressed in a coherent way and in an easy-to-use 
approach.

By the way, as far as I know, the Linux kernel does not [need to] save 
tunnel data or ARP entries behind "netdevice" structures.

PS : in the "rte_eth_tunnel_conf" data structure, I think that the first 
field should be named "rx_queue" instead of "tx_queue".

Regards,
Ivan

-- 
Ivan Boule
6WIND Development Engineer

[dpdk-dev] releases scheduling

[Jay Rolette]

+100 for the LTS

One of the bigger challenges for products using DPDK is that there is so
much change going in each release with very limited testing. Trying to even
remotely keep up is too risky. We end up back-porting various fixes and
enhancements to whatever version we are on (1.6rc2 currently).

Jay

On Tue, Dec 15, 2015 at 8:42 AM, Wiles, Keith  wrote:

> On 12/15/15, 7:37 AM, "dev on behalf of O'Driscoll, Tim" <
> dev-bounces at dpdk.org on behalf of tim.odriscoll at intel.com> wrote:
>
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> >> Sent: Sunday, December 13, 2015 7:23 PM
> >> To: dev at dpdk.org
> >> Subject: [dpdk-dev] releases scheduling
> >>
> >> Hi all,
> >>
> >> We need to define the deadlines for the next releases.
> >> During 2015, we were doing a release every 4 months.
> >> If we keep the same pace, the next releases would be:
> >>  2.3: end of March
> >>  2.4: end of July
> >>  2.5: end of November
> >>
> >> However, things move fast and it may be a bit long to wait 4 months for
> >> a feature. That's why I suggest to progressively shorten release terms:
> >>  2.3: end of March
> >>  2.4: mid July
> >>  2.5: end of October
> >> and continue with a release every 3 months:
> >>  2.6: end of January
> >>  2.7: end of April
> >>  2.8: end of July
> >> This planning would preserve some of the major holiday periods
> >> (February, May, August, December).
> >>
> >> The first period, for the first submission of a feature, was 2 months
> >> long.
> >> Then we had 2 other months to discuss, merge and fix.
> >> We should shorten only the first period.
> >>
> >> Anyway, the next deadlines should be unchanged:
> >>  - January 31: end of first submission phase
> >>  - March 31: release 2.3
> >>
> >> Opinions are welcome.
> >
> >I think moving to quarterly releases is a good idea. Your proposal to do
> this in a gradual way, so that we don't change the 2.3 dates, also makes
> sense.
> >
> >Should we consider changing the release numbering at the same time? It's
> difficult to keep track of when each 2.x release is due, and we don't have
> any criteria in place for moving to 3.x in future. Many people like the
> Ubuntu numbering scheme of Year.Month. Should we consider adopting that
> convention? If we move in future to a model where we have long-term support
> releases (something that was touched on in Dublin), then we could append an
> LTS designation to the release number.
>
> +1 for the Ubuntu number and the LTS
> >
> >
> >Tim
> >
>
>
> Regards,
> Keith
>
>
>
>
>

[dpdk-dev] [PATCH] doc: fix spellings in docs

[John McNamara]

Fix various spellings in rst docs.

Signed-off-by: John McNamara 
---
 doc/guides/contributing/coding_style.rst |  2 +-
 doc/guides/contributing/versioning.rst   |  2 +-
 doc/guides/cryptodevs/aesni_mb.rst   |  2 +-
 doc/guides/nics/bnx2x.rst|  6 +++---
 doc/guides/nics/nfp.rst  |  2 +-
 doc/guides/nics/szedata2.rst |  4 ++--
 doc/guides/prog_guide/env_abstraction_layer.rst  |  2 +-
 doc/guides/prog_guide/hash_lib.rst   |  2 +-
 doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst |  2 +-
 doc/guides/prog_guide/overview.rst   |  2 +-
 doc/guides/prog_guide/packet_framework.rst   | 12 ++--
 doc/guides/rel_notes/release_1_8.rst |  2 +-
 doc/guides/sample_app_ug/performance_thread.rst  |  2 +-
 doc/guides/sample_app_ug/tep_termination.rst |  2 +-
 doc/guides/sample_app_ug/test_pipeline.rst   |  6 +++---
 15 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/doc/guides/contributing/coding_style.rst 
b/doc/guides/contributing/coding_style.rst
index 22f26dd..ad1392d 100644
--- a/doc/guides/contributing/coding_style.rst
+++ b/doc/guides/contributing/coding_style.rst
@@ -461,7 +461,7 @@ Local Variables
 * When declaring variables in functions, multiple variables per line are OK.
   However, if multiple declarations would cause the line to exceed a 
reasonable line length, begin a new set of declarations on the next line rather 
than using a line continuation.
 * Be careful to not obfuscate the code by initializing variables in the 
declarations, only the last variable on a line should be initialized.
-  If multiple variables are to be initialised when defined, put one per line.
+  If multiple variables are to be initialized when defined, put one per line.
 * Do not use function calls in initializers, except for ``const`` variables.

 .. code-block:: c
diff --git a/doc/guides/contributing/versioning.rst 
b/doc/guides/contributing/versioning.rst
index d69a5c3..ae10a98 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -261,7 +261,7 @@ with the public symbol name
 struct rte_acl_ctx *ctx;
 ...

-Note that the base name of the symbol was kept intact, as this is condusive to
+Note that the base name of the symbol was kept intact, as this is conducive to
 the macros used for versioning symbols.  That is our next step, mapping this 
new
 symbol name to the initial symbol name at version node 2.0.  Immediately after
 the function, we add this line of code
diff --git a/doc/guides/cryptodevs/aesni_mb.rst 
b/doc/guides/cryptodevs/aesni_mb.rst
index 2ff5c41..0f4b920 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -32,7 +32,7 @@ AESN-NI Multi Buffer Crytpo Poll Mode Driver


 The AESNI MB PMD (**librte_pmd_aesni_mb**) provides poll mode crypto driver
-support for utilising Intel multi buffer library, see the white paper
+support for utilizing Intel multi buffer library, see the white paper
 `Fast Multi-buffer IPsec Implementations on Intel? Architecture Processors
 
`_.

diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst
index 85ac1c3..ed0e5e5 100644
--- a/doc/guides/nics/bnx2x.rst
+++ b/doc/guides/nics/bnx2x.rst
@@ -81,7 +81,7 @@ Supported QLogic NICs
 Prerequisites
 -

-- Requires firmware version **7.2.51.0**. It is inbox on most of the
+- Requires firmware version **7.2.51.0**. It is included in most of the
   standard Linux distros. If it is not available visit
   `QLogic Driver Download Center `_
   to get the required firmware.
@@ -313,7 +313,7 @@ This section provides instructions to configure SR-IOV with 
Linux OS.

 #. Assign VF MAC address:

-   Assign MAC address to the VF using iproute2 ulility. The syntax is:
+   Assign MAC address to the VF using iproute2 utility. The syntax is:
ip link set  vf  mac 

Example output:
@@ -323,7 +323,7 @@ This section provides instructions to configure SR-IOV with 
Linux OS.
   ip link set ens5f0 vf 0 mac 52:54:00:2f:9d:e8


-#. PCI passthrough:
+#. PCI Passthrough:

The VF devices may be passed through to the guest VM using virt-manager or
virsh etc. bnx2x PMD should be used to bind the VF devices in the guest VM
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index 55ba64d..dfc3683 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -126,7 +126,7 @@ Using the NFP PMD is not different to using other PMDs. 
Usual steps are:

   cat /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages

-   The hugepages reservation 

[dpdk-dev] [PATCH 2/2] ethdev: remove old flow director symbols

[Neil Horman]

On Tue, Dec 15, 2015 at 01:41:53PM +0200, Panu Matilainen wrote:
> On 12/15/2015 12:47 PM, Thomas Monjalon wrote:
> >The API has been removed but the symbols were still declared in the map.
> >
> >Fixes: a421b86a4a02 ("ethdev: remove old flow director API")
> >
> >Signed-off-by: Thomas Monjalon 
> >---
> >  lib/librte_ether/rte_ether_version.map | 8 
> >  1 file changed, 8 deletions(-)
> >
> >diff --git a/lib/librte_ether/rte_ether_version.map 
> >b/lib/librte_ether/rte_ether_version.map
> >index 17a11c7..d8db24d 100644
> >--- a/lib/librte_ether/rte_ether_version.map
> >+++ b/lib/librte_ether/rte_ether_version.map
> >@@ -27,14 +27,6 @@ DPDK_2.2 {
> > rte_eth_dev_count;
> > rte_eth_dev_default_mac_addr_set;
> > rte_eth_dev_detach;
> >-rte_eth_dev_fdir_add_perfect_filter;
> >-rte_eth_dev_fdir_add_signature_filter;
> >-rte_eth_dev_fdir_get_infos;
> >-rte_eth_dev_fdir_remove_perfect_filter;
> >-rte_eth_dev_fdir_remove_signature_filter;
> >-rte_eth_dev_fdir_set_masks;
> >-rte_eth_dev_fdir_update_perfect_filter;
> >-rte_eth_dev_fdir_update_signature_filter;
> > rte_eth_dev_filter_ctrl;
> > rte_eth_dev_filter_supported;
> > rte_eth_dev_flow_ctrl_get;
> >
> 
> Good spotting. What did you use find these and the ones in eal? Just
> thinking this seems like something that could and should be automated.
> 
>   - Panu -
> 
You can likely do it with this command:
nm  -A ./*.o | grep  | wc -l

or something simmilar.  nm -A dysplays all the symbols in an object file.  if
you grep for your sym and wc -l returns more than 1 line, the symbols has a
reference, and can't be removed.  Note it needs to be more than 1 line, as you
have to account for the object defining the symbol

Neil

[dpdk-dev] [PATCH] doc: announce ABI change for link speed

[Olga Shern]

Acked-by: Olga Shern 

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Tuesday, December 15, 2015 9:21 AM
To: dev at dpdk.org
Cc: Marc Sune ; Olga Shern ; 
Matej Vido 
Subject: [PATCH] doc: announce ABI change for link speed

A rework was prepared by Marc Sune:
http://dpdk.org/ml/archives/dev/2015-October/026037.html
The goal is to retrieve the supported link speed of a device and to allow 100G 
devices while having a consistent API.

Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index a4abb08..f8a41dd 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -12,6 +12,9 @@ Deprecation Notices
   ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
   tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff

+* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
+  must be updated to support 100G link and to have a cleaner link speed API.
+
 * ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
   which handles at most 256 entries (8 bits) while newer NICs support larger
   tables (512 entries).
--
2.5.2

[dpdk-dev] [PATCH] scripts: fix abi-validator regression when revision is a tag

[Neil Horman]

On Tue, Dec 15, 2015 at 03:55:15PM +0200, Panu Matilainen wrote:
> Commit 9cbae2aa64eb managed to break the only previously supported
> case where a tag is used as a revision, due to git show output
> differing between tags and other objects. The hash is on the last
> line of the output in both cases though so just grab that.
> 
> Fixes: 9cbae2aa64eb ("scripts: support any git revisions as ABI validation 
> range")
> Signed-off-by: Panu Matilainen 
> ---
>  scripts/validate-abi.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/validate-abi.sh b/scripts/validate-abi.sh
> index 8d7be24..c36ad61 100755
> --- a/scripts/validate-abi.sh
> +++ b/scripts/validate-abi.sh
> @@ -121,8 +121,8 @@ then
>   cleanup_and_exit 1
>  fi
>  
> -HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null)
> -HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null)
> +HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
> +HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)
>  
>  # Make sure our tags exist
>  res=$(validate_tags)
> -- 
> 2.5.0
> 
> 
Acked-by: Neil Horman 

[dpdk-dev] [PATCH] doc: announce ABI change for link speed

[Thomas Monjalon]

A rework was prepared by Marc Sune:
http://dpdk.org/ml/archives/dev/2015-October/026037.html
The goal is to retrieve the supported link speed of a device
and to allow 100G devices while having a consistent API.

Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index a4abb08..f8a41dd 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -12,6 +12,9 @@ Deprecation Notices
   ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
   tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff

+* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf
+  must be updated to support 100G link and to have a cleaner link speed API.
+
 * ABI changes is planned for the reta field in struct rte_eth_rss_reta_entry64
   which handles at most 256 entries (8 bits) while newer NICs support larger
   tables (512 entries).
-- 
2.5.2

[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_tunnel_filter_conf

[Thomas Monjalon]

> > Signed-off-by: Jingjing Wu  
> Acked-by: Wenzhuo Lu 
> Acked-by: Helin Zhang 
> Acked-by: Thomas Monjalon 

Applied, thanks

[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow

[Thomas Monjalon]

> > Signed-off-by: Jingjing Wu 
> Acked-by: Wenzhuo Lu 
> Acked-by: Helin Zhang 
> Acked-by: Andrey Chilikin 

Applied, thanks

[dpdk-dev] [PATCH 2/2] doc: announce ABI change for RETA configuration

[Thomas Monjalon]

> > Signed-off-by: Nelio Laranjeiro 
> Acked-by: Wenzhuo Lu 
> Acked-by: Thomas Monjalon 
> Acked-by: Olga Shern 

Applied, thanks