[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[Ananyev, Konstantin]

Hi,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Kerur
> Sent: Thursday, January 15, 2015 8:34 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> 
> On Wed, Jan 14, 2015 at 8:27 AM, Thomas Monjalon  6wind.com>
> wrote:
> 
> > 2015-01-09 04:41, Ravi Kerur:
> > > Thomas,
> > >
> > > Please let me know how I can move forward on this. If i confine changes
> > in
> > > e1000/ directory to e1000_osdep.h file only and the rest in PMD will that
> > > work? The reason I ask is because of following comment  in README file.
> > >
> > > ...
> > > Few changes to the original FreeBSD sources were made to:
> > > - Adopt it for PMD usage mode:
> > > e1000_osdep.c
> > > e1000_osdep.h
> > > ...

Yes, if needed you can modify these files.
In fact, these files are the only 2 that are allowed to be modified inside 
e1000 sub-directory.
As I understand you plan to implement E1000_READ_FLASH_REG  and 
E1000_WRITE_FLASH_REG
macros properly, correct?
Konstantin

> >
> > This is an Intel driver so you should ask to the responsible of this code
> > at Intel.
> > The problem is that there is not really an identified responsible for this
> > driver.
> >
> > The rule is to not change the base driver, even osdep files.
> > But it would be better to have an exception here.
> >
> >
> > PS: please avoid top-posting.
> >
> 
>  Please let me know who is the contact person from Intel so I can add
> him/her to "To" list when I send the patch or Should I contact Jim St Leger
> and ask him about this?
> 
> Thanks.
> 
> >
> > > On Mon, Jan 5, 2015 at 8:40 AM, Ravi Kerur  wrote:
> > >
> > > > Inline 
> > > >
> > > > On Mon, Jan 5, 2015 at 12:55 AM, Thomas Monjalon <
> > > > thomas.monjalon at 6wind.com> wrote:
> > > >
> > > >> 2015-01-04 15:28, Ravi Kerur:
> > > >> > We have a Gigabyte H97N motherboard which has I217 Intel chipset
> > which
> > > >> uses
> > > >> > e100e drivers. I looked into lib/librte_pmd_e1000 directory and I
> > do see
> > > >> > that e1000e code is integrated but missing some support for
> > read/write
> > > >> from
> > > >> > flash_address and other minor things. I have made changes shown
> > below
> > > >> and
> > > >> > have done some testing with testpmd utility and now have following
> > > >> questions
> > > >> >
> > > >> > 1. What amount of testing is required to qualify patch as
> > successfully
> > > >> > tested on new chipsets
> > > >>
> > > >> There is no good answer to this question. Generally, you must be sure
> > that
> > > >> you don't break anything.
> > > >> So you must test the code paths you have changed.
> > > >>
> > > >
> > > >  yes I have done testing on Ubuntu for I217 using testpmd.
> > > >
> > > >>
> > > >> > 2. FreeBSD testing, currently we have Ubuntu 14.04 installed on
> > existing
> > > >> > H97N motherboard and testing is done solely on Linux. We plan to get
> > > >> > another motherboard which will have I218 chipset and still deciding
> > > >> whether
> > > >> > to go with FreeBSD or Ubuntu. So the question I have is what amount
> > of
> > > >> > testing should be done on FreeBSD? I don't think
> > > >> setup.sh/dpdk_nic_bind.py
> > > >> > works on FreeBSD yet hence the question on testing.
> > > >>
> > > >> FreeBSD testing is required when patching common EAL, scripts or
> > > >> makefiles.
> > > >>
> > > >> > >  lib/librte_pmd_e1000/e1000/e1000_api.c  | 21
> > > >> +
> > > >> > >  lib/librte_pmd_e1000/e1000/e1000_api.h  |  1 +
> > > >> > >  lib/librte_pmd_e1000/e1000/e1000_osdep.h| 24
> > > >> +++-
> > > >>
> > > >> These files are part of the base driver.
> > > >> The rule is to not patch them and try to do the changes in PMD only.
> > > >> There can be exceptions if an Intel maintainer acknowledges it.
> > > >>
> > > >
> > > >   Changes in these files are modifying existing macros
> > > >
> > > > E1000_READ_FLASH_REG,
> > > > E1000_WRITE_FLASH_REG
> > > > ...
> > > >
> > > > If it is not recommended to modify these files, should I move macros
> > into
> > > > some PMD file?
> > > >
> > > > Thanks.
> >
> >

[dpdk-dev] Why nothing since 1.8.0?

[Thomas Monjalon]

2015-01-15 13:51, Neil Horman:
> On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
> > 2015-01-15 08:06, Neil Horman:
> > > Ok, I think what you're saying here is you're too busy to handle all the 
> > > patches
> > > comming in at the moment.  As such I'd like to propose a sub-tree 
> > > encompassing
> > > all the pmds in DPDK.  I would envision that including all the acutal 
> > > pmd's in
> > > the tree, as well as the infrastructure that is used to interface them to 
> > > the
> > > core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the patch 
> > > pool
> > > and send you pull requests.
> > 
> > The list of PMDs is increasing:
> > librte_pmd_af_packet
> > librte_pmd_bond
> > librte_pmd_e1000
> > librte_pmd_enic
> > librte_pmd_i40e
> > librte_pmd_ixgbe
> > librte_pmd_pcap
> > librte_pmd_ring
> > librte_pmd_virtio
> > librte_pmd_vmxnet3
> > librte_pmd_xenvirt
> > There is already some sub-trees for bnx2x, fm10k and i40e:
> > http://dpdk.org/browse/
> > 
> Yes, and I've mentioned before that that is an absolutely silly way to break 
> out
> subtrees.  You have to find a balance of workload distribution and developer
> convienience.

Intel requested fm10k and i40e sub-trees because there are many developments
in progress. We want to experience this model.

> I also note that these are problematic because you're not merging anything
> from them. Is it your intention to keep bnx2 and fm10k separate in perpituity?

No, I'll merge them on pull requests.
Note that they are planned for version 2.0 but not available yet.

> If so, thats a real problem, because then we effectively just have several out
> of tree drivers, and thats just unacceptible.

I don't understand what make you thinking that. They are -next tree, not out of 
tree.

> > > If you could set me up with a login to dpdk.org, I'd appreciate it.
> > 
> > It is preferred to have 1 sub-tree per module.
> > What do you think of managing contributions for af_packet and/or virtio?
> > It would make sense as virtio is a RedHat technology.
> > Maybe it could include vhost lib and example.
> > 
> No, for reasons I've mentioned before.  If you take each pmd/library and 
> create
> a subtree for it, you've created the most fine grained control of subtrees you
> could ask for, but you've created a nighmare of a burden on developers who 
> want
> to update any code, especially if they have patches that hit multiple trees.

It's not planned to have a sub-tree for each library.
And some sub-trees can be closed when activity decrease.

> Look at some of the stats in the dpdk tree:
> 
> Library   Commits between 1.7.0 and 1.8.0
> librte_acl5
> librte_cfgfile0
> librte_cmdline4
> librte_compat 0
> librte_distributor5
> librte_eal125
> librte_ether  31
> librte_hash   1
> librte_ip_frag5
> librte_ivshmem0
> librte_kni2
> librte_kvargs 0
> librte_lpm1
> librte_malloc 1
> librte_mbuf   39
> librte_mempool4
> librte_meter  0
> librte_net4
> librte_pipeline   0
> librte_pmd_af_packet  4
> librte_pmd_bond   20
> librte_pmd_e1000  21
> librte_pmd_enic   12
> librte_pmd_i40e   90
> librte_pmd_ixgbe  83
> librte_pmd_pcap   4
> librte_pmd_ring   0
> librte_pmd_virtio 21
> librte_pmd_vmxnet321
> librte_pmd_xenvirt6
> librte_port   6
> librte_power  3
> librte_ring   2
> librte_sched  1
> librte_table  7
> librte_timer  0
> librte_vhost  30
> 
> If you look at all of the pmds in the dpdk tree, we're talking about ~300
> patches per release.  If you look at the net-next tree for the linux kernel,
> Dave Miller merged 569 patches on his own (based on the following command:
> git log --pretty=format:%H v3.17..v3.18 -- drivers/net/ethernet/ net/core/ | 
> wc
> -l)
> 
> And that doesn't account for the ~500 patches that come in via pull request 
> from
> the wireless subtree.  Nor does it account for the merge window for net-next
> being 2 months instead of dpdk's 6 months.  Theres no need in any way for 12
> maintainers to be twiddling their thumbs waiting on ~20 patches each, and for
> that split, you've forced developers to potentially develop patches against 12
> trees (12 being the current number of PMD's that are in the dpdk).

Please stop on this wrong assumption. We keep only 1 mailing-list and use only
few sub-trees.

> The right answer here is balance.  Let me split out the pmd's and ethernet
> infrastructure libraries to a subtree.  I'll pull in patches posted regarding
> pmd's and librte_ether/ip_frag etc, and send you a pull requests after each
> release so you get all the latest bits, and then pulls for stabilization on 
> each
> -rc. I can manage 300 patches without issu

[dpdk-dev] [PATCH] librte_pmd_ixgbe: Add queue start failure check

[Michael Qiu]

For ixgbe, when queue start failure, for example, mbuf allocate
failure, the device will still start success, which could be
an issue.

Add return status check of queue start to avoid this issue.

Signed-off-by: Michael Qiu 
---
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c |  6 +-
 lib/librte_pmd_ixgbe/ixgbe_ethdev.h |  2 +-
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 22 +-
 3 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index 3fc3738..59e3321 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -1491,7 +1491,11 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
goto error;
}

-   ixgbe_dev_rxtx_start(dev);
+   err = ixgbe_dev_rxtx_start(dev);
+   if (err < 0) {
+   PMD_INIT_LOG(ERR, "Unable to start rxtx queues\n");
+   goto error;
+   }

if (ixgbe_is_sfp(hw) && hw->phy.multispeed_fiber) {
err = hw->mac.ops.setup_sfp(hw);
diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.h 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
index ca99170..7461450 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
@@ -251,7 +251,7 @@ int ixgbe_dev_rx_init(struct rte_eth_dev *dev);

 void ixgbe_dev_tx_init(struct rte_eth_dev *dev);

-void ixgbe_dev_rxtx_start(struct rte_eth_dev *dev);
+int ixgbe_dev_rxtx_start(struct rte_eth_dev *dev);

 int ixgbe_dev_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id);

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index e10d6a2..41a930e 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -3744,7 +3744,7 @@ ixgbe_setup_loopback_link_82599(struct ixgbe_hw *hw)
 /*
  * Start Transmit and Receive Units.
  */
-void
+int
 ixgbe_dev_rxtx_start(struct rte_eth_dev *dev)
 {
struct ixgbe_hw *hw;
@@ -3754,6 +3754,7 @@ ixgbe_dev_rxtx_start(struct rte_eth_dev *dev)
uint32_t dmatxctl;
uint32_t rxctrl;
uint16_t i;
+   int ret = 0;

PMD_INIT_FUNC_TRACE();
hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
@@ -3776,14 +3777,24 @@ ixgbe_dev_rxtx_start(struct rte_eth_dev *dev)

for (i = 0; i < dev->data->nb_tx_queues; i++) {
txq = dev->data->tx_queues[i];
-   if (!txq->tx_deferred_start)
-   ixgbe_dev_tx_queue_start(dev, i);
+   if (!txq->tx_deferred_start) {
+   ret = ixgbe_dev_tx_queue_start(dev, i);
+   if (ret < 0) {
+   PMD_INIT_LOG(ERR, "Start tx queue failed\n");
+   return ret;
+   }
+   }
}

for (i = 0; i < dev->data->nb_rx_queues; i++) {
rxq = dev->data->rx_queues[i];
-   if (!rxq->rx_deferred_start)
-   ixgbe_dev_rx_queue_start(dev, i);
+   if (!rxq->rx_deferred_start) {
+   ret = ixgbe_dev_rx_queue_start(dev, i);
+   if (ret < 0) {
+   PMD_INIT_LOG(ERR, "Start rx queue failed\n");
+   return ret;
+   }
+   }
}

/* Enable Receive engine */
@@ -3798,6 +3809,7 @@ ixgbe_dev_rxtx_start(struct rte_eth_dev *dev)
dev->data->dev_conf.lpbk_mode == IXGBE_LPBK_82599_TX_RX)
ixgbe_setup_loopback_link_82599(hw);

+   return 0;
 }

 /*
-- 
1.9.3

[dpdk-dev] Why nothing since 1.8.0?

[O'driscoll, Tim]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Thursday, January 15, 2015 6:51 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Why nothing since 1.8.0?
> 
> On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
> > 2015-01-15 08:06, Neil Horman:
> > > On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote:
> > > > 2015-01-15 04:27, Ouyang, Changchun:
> > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> > > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil
> Horman
> > > > > > > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger
> wrote:
> > > > > > > > Ok, so 1.8.0 came out almost a month ago and none of the
> patches
> > > > > > > > that were deferred waiting for the release got merged since
> then.
> > > > > > > > Last commit in git is the 1.8.0 release.
> > > > > > > >
> > > > > > > > Where is the post-merge window bundle, where are the later
> commits?
> > > > > > > > Lots of patches are sitting rotting in patchwork...
> > > > > > >
> > > > > > > +1, I've had the same questions.
> > > > > > > Neil
> > > > > >
> > > > > > +1, Some patch set might be ready for being merged.
> > > > >
> > > > > +1,  the earlier some patches are merged into mainline, and the easier
> those
> > > > > sequent patch sets can resolve their conflicts.
> > > >
> > > > +1, there are some patches which are properly reviewed
> > > >
> > > > Reminder: sub-tree to manage specific part of DPDK can be open on
> request
> > >
> > > Ok, I think what you're saying here is you're too busy to handle all the
> patches
> > > comming in at the moment.  As such I'd like to propose a sub-tree
> encompassing
> > > all the pmds in DPDK.  I would envision that including all the acutal 
> > > pmd's
> in
> > > the tree, as well as the infrastructure that is used to interface them to 
> > > the
> > > core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the patch 
> > > pool
> > > and send you pull requests.
> >
> > The list of PMDs is increasing:
> > librte_pmd_af_packet
> > librte_pmd_bond
> > librte_pmd_e1000
> > librte_pmd_enic
> > librte_pmd_i40e
> > librte_pmd_ixgbe
> > librte_pmd_pcap
> > librte_pmd_ring
> > librte_pmd_virtio
> > librte_pmd_vmxnet3
> > librte_pmd_xenvirt
> > There is already some sub-trees for bnx2x, fm10k and i40e:
> > http://dpdk.org/browse/
> >
> Yes, and I've mentioned before that that is an absolutely silly way to break
> out
> subtrees.  You have to find a balance of workload distribution and developer
> convienience.
> 
> I also note that these are problematic because you're not merging anything
> from them. Is it your intention to keep bnx2 and fm10k separate in
> perpituity?
> If so, thats a real problem, because then we effectively just have several out
> of tree drivers, and thats just unacceptible.
> 
> > > If you could set me up with a login to dpdk.org, I'd appreciate it.
> >
> > It is preferred to have 1 sub-tree per module.
> > What do you think of managing contributions for af_packet and/or virtio?
> > It would make sense as virtio is a RedHat technology.
> > Maybe it could include vhost lib and example.
> >
> No, for reasons I've mentioned before.  If you take each pmd/library and
> create
> a subtree for it, you've created the most fine grained control of subtrees you
> could ask for, but you've created a nighmare of a burden on developers who
> want
> to update any code, especially if they have patches that hit multiple trees.
> 
> Look at some of the stats in the dpdk tree:
> 
> Library   Commits between 1.7.0 and 1.8.0
> librte_acl5
> librte_cfgfile0
> librte_cmdline4
> librte_compat 0
> librte_distributor5
> librte_eal125
> librte_ether  31
> librte_hash   1
> librte_ip_frag5
> librte_ivshmem0
> librte_kni2
> librte_kvargs 0
> librte_lpm1
> librte_malloc 1
> librte_mbuf   39
> librte_mempool4
> librte_meter  0
> librte_net4
> librte_pipeline   0
> librte_pmd_af_packet  4
> librte_pmd_bond   20
> librte_pmd_e1000  21
> librte_pmd_enic   12
> librte_pmd_i40e   90
> librte_pmd_ixgbe  83
> librte_pmd_pcap   4
> librte_pmd_ring   0
> librte_pmd_virtio 21
> librte_pmd_vmxnet321
> librte_pmd_xenvirt6
> librte_port   6
> librte_power  3
> librte_ring   2
> librte_sched  1
> librte_table  7
> librte_timer  0
> librte_vhost  30
> 
> If you look at all of the pmds in the dpdk tree, we're talking about ~300
> patches per release.  If you look at the net-next tree for the linux kernel,
> Dave Miller merged 569 patches on his own (based on the following
> command:
> git log --pretty=f

[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[O'driscoll, Tim]

> On Thursday, January 15, 2015  at 8:34 PM, Ravi Kerur  
> wrote:
> 
> On Wed, Jan 14, 2015 at 8:27 AM, Thomas Monjalon
> 
> wrote:
> 
> > 2015-01-09 04:41, Ravi Kerur:
> > > Thomas,
> > >
> > > Please let me know how I can move forward on this. If i confine changes
> > in
> > > e1000/ directory to e1000_osdep.h file only and the rest in PMD will that
> > > work? The reason I ask is because of following comment  in README file.
> > >
> > > ...
> > > Few changes to the original FreeBSD sources were made to:
> > > - Adopt it for PMD usage mode:
> > > e1000_osdep.c
> > > e1000_osdep.h
> > > ...
> >
> > This is an Intel driver so you should ask to the responsible of this code
> > at Intel.
> > The problem is that there is not really an identified responsible for this
> > driver.
> >
> > The rule is to not change the base driver, even osdep files.
> > But it would be better to have an exception here.
> >
> >
> > PS: please avoid top-posting.
> >
> 
>  Please let me know who is the contact person from Intel so I can add
> him/her to "To" list when I send the patch or Should I contact Jim St Leger
> and ask him about this?

We're looking into this, but don't have a definitive answer yet. Somebody from 
Intel will reply as soon as we've confirmed whether the change you proposed is 
OK or not.


Tim

[dpdk-dev] Does I210 NIC support Flow director filters?

[Kamraan Nasim]

>>> update the RSS RETA table so that traffic doesn't get sent
>> to that queue via RSS. Is that what you are asking?

Thanks Bruce, that's exactly it.  Basically each filter will forward
traffic to a unique RSS queue which can allow me to calculate filter match
statistics for that queue(or filter). At that point I would like to drop
the filtered packet. Is there any way to drop the filtered packet in the
RSS queue without doing a rte_eth_rx_burst() and dropping it then?

--Kam

On Thu, Jan 15, 2015 at 9:44 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:

> On Wed, Jan 14, 2015 at 04:59:17PM -0500, Kamraan Nasim wrote:
> > Many thanks Helin and Bruce :)
> >
> > Now if 1Gb NICs don't support fdir filters then im wondering how would we
> > count the number of packets matching a filter.
> >
> > Regular 5tuple filters don't have any stats similar to "fdirmatch"(in the
> > rte_eth_stats 
> struct).
> > One way I can think of is to use regular ibytes/ipackets stats for the
> > queue to which the packets are being redirected in the 5tuple filter but
> > this seems a bit hacky + there is no way to distinguish this packet
> > throughput from the regular traffic that the NIC is forwarding to that
> > specific queue.
> >
> > Is there a way to EXCLUSIVELY bind a 5tuple filter to an RSS queue so
> that
> > only matched traffic is forwarded there?
> >
> >
> > --Kam
> >
>
> What you can do is use a 5-tuple filter to send traffic to a queue. What
> you
> can also do is update the RSS RETA table so that traffic doesn't get sent
> to that queue via RSS. Is that what you are asking?
>
> /Bruce
>
> > On Wed, Jan 14, 2015 at 5:27 AM, Bruce Richardson <
> > bruce.richardson at intel.com> wrote:
> >
> > > On Tue, Jan 13, 2015 at 11:21:08PM -0500, Kamraan Nasim wrote:
> > > > Hello,
> > > >
> > > > I've been using DPDK fdir filter APIs for 82599 NIC(Niantic) and they
> > > work
> > > > very well.
> > > >
> > > > Was wondering if I these could also be used for I210, 1Gbps NICs?
> > > >
> > > > The other option is to use 5tuple
> filters(rte_eth_dev_add_5tuple_filter
> > > > <
> > >
> http://dpdk.org/doc/api/rte__ethdev_8h.html#aaa28adafa65a4f47d4aeceaf1b08381b
> > > >),
> > > > however these do not support IPv6 yet.
> > > >
> > > >
> > > > Have people in the community had any luck with configuring L3/L4
> hardware
> > > > filters for the I210 NIC?
> > > >
> > > > Thanks,
> > > > Kam
> > >
> > > Flow director filters are not supported for 1G NICs. Sorry.
> > >
> > > /Bruce
> > >
>

[dpdk-dev] Why nothing since 1.8.0?

[Thomas Monjalon]

2015-01-15 08:06, Neil Horman:
> On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote:
> > 2015-01-15 04:27, Ouyang, Changchun:
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > > > > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger wrote:
> > > > > > Ok, so 1.8.0 came out almost a month ago and none of the patches
> > > > > > that were deferred waiting for the release got merged since then.
> > > > > > Last commit in git is the 1.8.0 release.
> > > > > >
> > > > > > Where is the post-merge window bundle, where are the later commits?
> > > > > > Lots of patches are sitting rotting in patchwork...
> > > > >
> > > > > +1, I've had the same questions.
> > > > > Neil
> > > > 
> > > > +1, Some patch set might be ready for being merged.
> > > 
> > > +1,  the earlier some patches are merged into mainline, and the easier 
> > > those
> > > sequent patch sets can resolve their conflicts.
> > 
> > +1, there are some patches which are properly reviewed
> > 
> > Reminder: sub-tree to manage specific part of DPDK can be open on request
> 
> Ok, I think what you're saying here is you're too busy to handle all the 
> patches
> comming in at the moment.  As such I'd like to propose a sub-tree encompassing
> all the pmds in DPDK.  I would envision that including all the acutal pmd's in
> the tree, as well as the infrastructure that is used to interface them to the
> core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the patch pool
> and send you pull requests.

The list of PMDs is increasing:
librte_pmd_af_packet
librte_pmd_bond
librte_pmd_e1000
librte_pmd_enic
librte_pmd_i40e
librte_pmd_ixgbe
librte_pmd_pcap
librte_pmd_ring
librte_pmd_virtio
librte_pmd_vmxnet3
librte_pmd_xenvirt
There is already some sub-trees for bnx2x, fm10k and i40e:
http://dpdk.org/browse/

> If you could set me up with a login to dpdk.org, I'd appreciate it.

It is preferred to have 1 sub-tree per module.
What do you think of managing contributions for af_packet and/or virtio?
It would make sense as virtio is a RedHat technology.
Maybe it could include vhost lib and example.

Thanks for proposing
-- 
Thomas

[dpdk-dev] Why nothing since 1.8.0?

[Matthew Hall]

On Thu, Jan 15, 2015 at 09:55:00PM +, O'driscoll, Tim wrote:
> As you said, there's a balance to be struck, and too many subtrees may 
> become unmanageable. With respect to your concern about developers having to 
> potentially develop patches against multiple subtrees, this has never been 
> raised as a concern by any of our development team. Is there any historical 
> data on the number of changes that would fall into this category so we can 
> see if it's a real problem or not?

Hi Tim,

What happens when a core API like rte_mbuf gets some changes, and you have to 
update the PMD's to fit?

Do I have to make 10-20 odd random patches to separate PMD maintainers instead 
of one set of patches to the PMD subtree?

To me it doesn't sound very nice for the guys maintaining the core. Given most 
of the changes seem to be mbuf or eal this seems like a scaling issue to me.

But maybe I misunderstood the process.

Matthew.

[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[Ravi Kerur]

Thanks Tim, Konstantin and Helin. I will send out revised patch.

Thanks,
Ravi

On Thu, Jan 15, 2015 at 5:14 PM, Zhang, Helin  wrote:

>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Kerur
> > Sent: Monday, January 5, 2015 7:28 AM
> > To: dev at dpdk.org; Neil Horman; Thomas Monjalon
> > Subject: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> >
> > Hi,
> >
> > We have a Gigabyte H97N motherboard which has I217 Intel chipset which
> > uses e100e drivers. I looked into lib/librte_pmd_e1000 directory and I
> do see
> > that e1000e code is integrated but missing some support for read/write
> from
> > flash_address and other minor things. I have made changes shown below and
> > have done some testing with testpmd utility and now have following
> questions
> >
> > 1. What amount of testing is required to qualify patch as successfully
> tested on
> > new chipsets
> >
> > 2. FreeBSD testing, currently we have Ubuntu 14.04 installed on existing
> H97N
> > motherboard and testing is done solely on Linux. We plan to get another
> > motherboard which will have I218 chipset and still deciding whether to
> go with
> > FreeBSD or Ubuntu. So the question I have is what amount of testing
> should be
> > done on FreeBSD? I don't think setup.sh/dpdk_nic_bind.py works on
> FreeBSD
> > yet hence the question on testing.
> >
> > Thanks,
> > Ravi
> >
> >
> >
> > On Sun, Jan 4, 2015 at 3:15 PM, Ravi Kerur  wrote:
> >
> > > This patch adds support for I217 and I218 Intel chipsets.
> > > Gigabyte H97N motherboard has I217 Intel chipsets and changes include
> > >
> > > 1. Add relevant device-ids via RTE_PCI_DEV_ID_DECL_EM 2. Add support
> > > for memory mapped flash address read/write
> > >
> > > Basic testing on Ubuntu with testpmd utility.
> > >
> > > Signed-off-by: Ravi Kerur 
> > > ---
> > >  lib/librte_eal/common/include/rte_pci_dev_ids.h |  4 
> > >  lib/librte_pmd_e1000/e1000/e1000_api.c  | 21
> > +
> > >  lib/librte_pmd_e1000/e1000/e1000_api.h  |  1 +
> > >  lib/librte_pmd_e1000/e1000/e1000_osdep.h| 24
> > > +++-
> > >  lib/librte_pmd_e1000/em_ethdev.c|  7 +++
> > >  5 files changed, 52 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > index c922de9..712793a 100644
> > > --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > > @@ -274,6 +274,10 @@
> > RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > > E1000_DEV_ID_82572EI)
> > >  RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > E1000_DEV_ID_82573L)
> > > RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > E1000_DEV_ID_82574L)
> > > RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > E1000_DEV_ID_82574LA)
> > > +RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > > +E1000_DEV_ID_PCH_LPT_I217_LM)
> > > +RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > > +E1000_DEV_ID_PCH_LPT_I217_V)
> > > +RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > > E1000_DEV_ID_PCH_LPTLP_I218_LM)
> > > +RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > > +E1000_DEV_ID_PCH_LPTLP_I218_V)
> So, you are enabling new Intel(r) NICs. That's great, and thanks!
>
> > >
> > >  / Physical IGB devices from e1000_hw.h
> > > /
> > >
> > > diff --git a/lib/librte_pmd_e1000/e1000/e1000_api.c
> > > b/lib/librte_pmd_e1000/e1000/e1000_api.c
> > > index a064565..30ed1f3 100644
> > > --- a/lib/librte_pmd_e1000/e1000/e1000_api.c
> > > +++ b/lib/librte_pmd_e1000/e1000/e1000_api.c
> > > @@ -1355,3 +1355,24 @@ void e1000_shutdown_fiber_serdes_link(struct
> > > e1000_hw *hw)
> > > hw->mac.ops.shutdown_serdes(hw);  }
> > >
> > > +/**
> > > + *  e1000_device_is_ich8 - Check for ICH8 device
> > > + *  @hw: pointer to the HW structure
> > > + *
> > > + *  return TRUE for ICH8, otherwise FALSE  **/ bool
> > > +e1000_device_is_ich8(struct e1000_hw *hw) {
> > > +   DEBUGFUNC("e1000_device_is_ich8");
> > > +
> > > +   switch (hw->device_id) {
> > > +   case E1000_DEV_ID_PCH_LPT_I217_LM:
> > > +   case E1000_DEV_ID_PCH_LPT_I217_V:
> > > +   case E1000_DEV_ID_PCH_LPTLP_I218_LM:
> > > +   case E1000_DEV_ID_PCH_LPTLP_I218_V:
> > > +   return 1;
> > > +
> > > +   default:
> > > +   return 0;
> > > +   }
> > > +}
> As Konstantin indicated, please do not try to modify any code in any
> source files in e1000
> sub-folder, except e1000_osdep.c and e1000_osdep.h. If this piece of code
> is needed, please
> try to move it to em_ethdev.c or e1000_osdep.c files!
>
> > > diff --git a/lib/librte_pmd_e1000/e1000/e1000_api.h
> > > b/lib/librte_pmd_e1000/e1000/e1000_api.h
> > > index 02b16da..f96a674 100644
> > > --- a/lib/librte_pmd_e1000/e1000/e1000_api.h
> > > +++ b/lib/librte_pmd_e1000/e1000/e1000_api.h
> > > @@ -49,6 +49,7 @@ exter

[dpdk-dev] [PATCH v6] VFIO: Avoid to enable vfio while the module not loaded

[Thomas Monjalon]

2015-01-15 13:42, Burakov, Anatoly:
> Yep, apologies, it's my fault as it was my suggestion.
> I knew there was a linuxapp-only EAL header, for some reason I thought it's 
> eal_private.
> Any suggestions on where to put this function? I don't think BSD needs this 
> function. 

No, it's OK. I think it could be needed in bsd if a PMD
depends on a kernel driver or try to unload one.

PS: please don't top post
-- 
Thomas


> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Thursday, January 15, 2015 1:38 PM
> > To: Qiu, Michael
> > Cc: Burakov, Anatoly; dev at dpdk.org; Xie, Huawei
> > Subject: Re: [PATCH v6] VFIO: Avoid to enable vfio while the module not
> > loaded
> > 
> > > > When vfio module is not loaded when kernel support vfio feature, the
> > > > routine still try to open the container to get file description.
> > > >
> > > > This action is not safe, and of cause got error messages:
> > > >
> > > > EAL: Detected 40 lcore(s)
> > > > EAL:   unsupported IOMMU type!
> > > > EAL: VFIO support could not be initialized
> > > > EAL: Setting up memory...
> > > >
> > > > This may make user confuse, this patch make it reasonable and much
> > > > more soomth to user.
> > > >
> > > > Signed-off-by: Michael Qiu 
> > >
> > > Acked-by: Anatoly Burakov 
> > 
> > Note that rte_eal_check_module has no bsd counterpart.
> > It could be needed later.
> > 
> > Applied
> > 
> > Thanks
> > --
> > Thomas

[dpdk-dev] Does I210 NIC support Flow director filters?

[Bruce Richardson]

On Wed, Jan 14, 2015 at 04:59:17PM -0500, Kamraan Nasim wrote:
> Many thanks Helin and Bruce :)
> 
> Now if 1Gb NICs don't support fdir filters then im wondering how would we
> count the number of packets matching a filter.
> 
> Regular 5tuple filters don't have any stats similar to "fdirmatch"(in the
> rte_eth_stats  struct).
> One way I can think of is to use regular ibytes/ipackets stats for the
> queue to which the packets are being redirected in the 5tuple filter but
> this seems a bit hacky + there is no way to distinguish this packet
> throughput from the regular traffic that the NIC is forwarding to that
> specific queue.
> 
> Is there a way to EXCLUSIVELY bind a 5tuple filter to an RSS queue so that
> only matched traffic is forwarded there?
> 
> 
> --Kam
> 

What you can do is use a 5-tuple filter to send traffic to a queue. What you
can also do is update the RSS RETA table so that traffic doesn't get sent
to that queue via RSS. Is that what you are asking?

/Bruce

> On Wed, Jan 14, 2015 at 5:27 AM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
> 
> > On Tue, Jan 13, 2015 at 11:21:08PM -0500, Kamraan Nasim wrote:
> > > Hello,
> > >
> > > I've been using DPDK fdir filter APIs for 82599 NIC(Niantic) and they
> > work
> > > very well.
> > >
> > > Was wondering if I these could also be used for I210, 1Gbps NICs?
> > >
> > > The other option is to use 5tuple filters(rte_eth_dev_add_5tuple_filter
> > > <
> > http://dpdk.org/doc/api/rte__ethdev_8h.html#aaa28adafa65a4f47d4aeceaf1b08381b
> > >),
> > > however these do not support IPv6 yet.
> > >
> > >
> > > Have people in the community had any luck with configuring L3/L4 hardware
> > > filters for the I210 NIC?
> > >
> > > Thanks,
> > > Kam
> >
> > Flow director filters are not supported for 1G NICs. Sorry.
> >
> > /Bruce
> >

[dpdk-dev] [PATCH] testpmd: remove duplicated function parse_item_list

[Thomas Monjalon]

> > There were two static functions called "parse_item_list" in testpmd app.
> > Since one was a superset of the functionality of the other, we can
> > collapse the two calls down into a single one, shared between the two
> > C files.
> > 
> > Signed-off-by: Bruce Richardson 
> 
> Acked-by: Pablo de Lara 

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH v2] bond: vlan flags misinterpreted in xmit_slave_hash function

[Thomas Monjalon]

> This patch contains a fix for link bonding handling of vlan tagged packets in 
> mode 3 and 5.
> Currently xmit_slave_hash function misinterprets the PKT_RX_VLAN_PKT flag to 
> mean that
> there is a vlan tag within the packet when in actually means that there is a 
> valid entry
> in the vlan_tci field in the mbuf.
> 
> -v2:
> doxygen comments for rte_ip.h
> 
> - Fixed VLAN tag support in hashing functions.
> - Adds support for TCP in layer 4 header hashing.
> - Splits transmit hashing function into separate functions for each policy to
>   reduce branching and to make the code clearer.
> - Fixed incorrect flag set in test application packet generator.
> 
> Signed-off-by: Declan Doherty 
Acked-by: Pawel Wodkowski 
Tested-by: SunX Jiajia 

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH v6] VFIO: Avoid to enable vfio while the module not loaded

[Thomas Monjalon]

> > When vfio module is not loaded when kernel support vfio feature, the
> > routine still try to open the container to get file description.
> > 
> > This action is not safe, and of cause got error messages:
> > 
> > EAL: Detected 40 lcore(s)
> > EAL:   unsupported IOMMU type!
> > EAL: VFIO support could not be initialized
> > EAL: Setting up memory...
> > 
> > This may make user confuse, this patch make it reasonable and much more
> > soomth to user.
> > 
> > Signed-off-by: Michael Qiu 
> 
> Acked-by: Anatoly Burakov 

Note that rte_eal_check_module has no bsd counterpart.
It could be needed later.

Applied

Thanks
-- 
Thomas

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

[Neil Horman]

Adding a document describing rudimentary ABI policy and adding notice space for
any deprecation announcements

Signed-off-by: Neil Horman 
CC: Thomas Monjalon 
CC: "Richardson, Bruce" 
---
 doc/abi.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 doc/abi.txt

diff --git a/doc/abi.txt b/doc/abi.txt
new file mode 100644
index 000..b6dcc7d
--- /dev/null
+++ b/doc/abi.txt
@@ -0,0 +1,17 @@
+ABI policy:
+   ABI versions are set at the time of major release labeling, and ABI may
+change multiple times between the last labeling and the HEAD label of the git
+tree without warning
+
+   ABI versions, once released are available until such time as their
+deprecation has been noted here for at least one major release cycle, after it
+has been tagged.  E.g. the ABI for DPDK 1.8 is shipped, and then the decision 
to
+remove it is made during the development of DPDK 1.9.  The decision will be
+recorded here, shipped with the DPDK 1.9 release, and actually removed when 
DPDK
+1.10 ships.
+
+   ABI versions may be deprecated in whole, or in part as needed by a given
+update.
+
+Deprecation Notices:
+
-- 
2.1.0

[dpdk-dev] [PATCH v4 3/4] Add library version extenstion

[Neil Horman]

To differentiate libraries that break ABI, we add a library version number
suffix to the library, which must be incremented when a given libraries ABI is
broken.  This patch enforces that addition, sets the initial abi soname
extension to 1 for each library and creates a symlink to the base SONAME so that
the test applications will link properly.

Signed-off-by: Neil Horman 
CC: Thomas Monjalon 
CC: "Richardson, Bruce" 

---
Change Notes:
v3)
Made symlinking of libraries conditional on a DSO build

v4) Removed erroneous newline
changed @exit 1 to @false
changed ./$(LIB) to $<
---
 lib/librte_acl/Makefile  |  2 ++
 lib/librte_cfgfile/Makefile  |  2 ++
 lib/librte_cmdline/Makefile  |  2 ++
 lib/librte_compat/Makefile   |  2 ++
 lib/librte_distributor/Makefile  |  2 ++
 lib/librte_eal/bsdapp/eal/Makefile   |  2 ++
 lib/librte_eal/linuxapp/eal/Makefile |  2 ++
 lib/librte_ether/Makefile|  2 ++
 lib/librte_hash/Makefile |  2 ++
 lib/librte_ip_frag/Makefile  |  2 ++
 lib/librte_ivshmem/Makefile  |  2 ++
 lib/librte_kni/Makefile  |  2 ++
 lib/librte_kvargs/Makefile   |  2 ++
 lib/librte_lpm/Makefile  |  2 ++
 lib/librte_malloc/Makefile   |  2 ++
 lib/librte_mbuf/Makefile |  2 ++
 lib/librte_mempool/Makefile  |  2 ++
 lib/librte_meter/Makefile|  2 ++
 lib/librte_pipeline/Makefile |  2 ++
 lib/librte_pmd_af_packet/Makefile|  2 ++
 lib/librte_pmd_bond/Makefile |  2 ++
 lib/librte_pmd_e1000/Makefile|  2 ++
 lib/librte_pmd_enic/Makefile |  2 ++
 lib/librte_pmd_i40e/Makefile |  2 ++
 lib/librte_pmd_ixgbe/Makefile|  2 ++
 lib/librte_pmd_pcap/Makefile |  2 ++
 lib/librte_pmd_ring/Makefile |  2 ++
 lib/librte_pmd_virtio/Makefile   |  2 ++
 lib/librte_pmd_vmxnet3/Makefile  |  2 ++
 lib/librte_pmd_xenvirt/Makefile  |  2 ++
 lib/librte_port/Makefile |  2 ++
 lib/librte_power/Makefile|  2 ++
 lib/librte_ring/Makefile |  2 ++
 lib/librte_sched/Makefile|  2 ++
 lib/librte_table/Makefile|  2 ++
 lib/librte_timer/Makefile|  2 ++
 lib/librte_vhost/Makefile|  2 ++
 mk/rte.lib.mk| 12 ++--
 38 files changed, 84 insertions(+), 2 deletions(-)

diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
index 45cbf80..765deb1 100644
--- a/lib/librte_acl/Makefile
+++ b/lib/librte_acl/Makefile
@@ -39,6 +39,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)

 EXPORT_MAP := rte_acl_version.map

+LIBABIVER := 1
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_ACL) += tb_mem.c

diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile
index a4f73de..032c240 100644
--- a/lib/librte_cfgfile/Makefile
+++ b/lib/librte_cfgfile/Makefile
@@ -41,6 +41,8 @@ CFLAGS += $(WERROR_FLAGS)

 EXPORT_MAP := rte_cfgfile_version.map

+LIBABIVER := 1
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_cmdline/Makefile b/lib/librte_cmdline/Makefile
index 3c71831..719dff6 100644
--- a/lib/librte_cmdline/Makefile
+++ b/lib/librte_cmdline/Makefile
@@ -38,6 +38,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3

 EXPORT_MAP := rte_cmdline_version.map

+LIBABIVER := 1
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := cmdline.c
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_cirbuf.c
diff --git a/lib/librte_compat/Makefile b/lib/librte_compat/Makefile
index 0bab870..0c57533 100644
--- a/lib/librte_compat/Makefile
+++ b/lib/librte_compat/Makefile
@@ -32,6 +32,8 @@
 include $(RTE_SDK)/mk/rte.vars.mk


+LIBABIVER := 1
+
 # install includes
 SYMLINK-y-include := rte_compat.h

diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile
index 3674a2c..4c9af17 100644
--- a/lib/librte_distributor/Makefile
+++ b/lib/librte_distributor/Makefile
@@ -39,6 +39,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)

 EXPORT_MAP := rte_distributor_version.map

+LIBABIVER := 1
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor.c

diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index 0b5f9d9..ae214a4 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -48,6 +48,8 @@ CFLAGS += $(WERROR_FLAGS) -O3

 EXPORT_MAP := rte_eal_version.map

+LIBABIVER := 1
+
 # specific to linuxapp exec-env
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) := eal.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_memory.c
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index bae8af1..e117cec 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -35,6 +35,8 @@ LIB = librte_eal.a

 EXPORT_MAP := rte_eal_version.map

+LIBABIVER := 1
+
 VPATH += $(RTE_SDK)/lib/librte_eal/common

 CFLAGS += -I$(SRCDI

[dpdk-dev] [PATCH v4 2/4] Provide initial versioning for all DPDK libraries

[Neil Horman]

Add linker version script files to each DPDK library to put a stake in the
ground from which we can start cleaning up API's

Signed-off-by: Neil Horman 
CC: Thomas Monjalon 
CC: "Richardson, Bruce" 

---
Change Notes:

v2)
* Updated export map to not require full path
---
 lib/librte_acl/Makefile|   2 +
 lib/librte_acl/rte_acl_version.map |  21 
 lib/librte_cfgfile/Makefile|   2 +
 lib/librte_cfgfile/rte_cfgfile_version.map |  14 +++
 lib/librte_cmdline/Makefile|   2 +
 lib/librte_cmdline/rte_cmdline_version.map |  69 +
 lib/librte_distributor/Makefile|   2 +
 lib/librte_distributor/rte_distributor_version.map |  16 +++
 lib/librte_eal/bsdapp/eal/Makefile |   2 +
 lib/librte_eal/bsdapp/eal/rte_eal_version.map  |  90 
 lib/librte_eal/linuxapp/eal/Makefile   |   2 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map|  90 
 lib/librte_ether/Makefile  |   2 +
 lib/librte_ether/rte_ether_version.map | 113 +
 lib/librte_hash/Makefile   |   2 +
 lib/librte_hash/rte_hash_version.map   |  18 
 lib/librte_ip_frag/Makefile|   2 +
 lib/librte_ip_frag/rte_ipfrag_version.map  |  14 +++
 lib/librte_ivshmem/Makefile|   2 +
 lib/librte_ivshmem/rte_ivshmem_version.map |  13 +++
 lib/librte_kni/Makefile|   2 +
 lib/librte_kni/rte_kni_version.map |  20 
 lib/librte_kvargs/Makefile |   2 +
 lib/librte_kvargs/rte_kvargs_version.map   |  10 ++
 lib/librte_lpm/Makefile|   2 +
 lib/librte_lpm/rte_lpm_version.map |  24 +
 lib/librte_malloc/Makefile |   2 +
 lib/librte_malloc/rte_malloc_version.map   |  19 
 lib/librte_mbuf/Makefile   |   2 +
 lib/librte_mbuf/rte_mbuf_version.map   |  14 +++
 lib/librte_mempool/Makefile|   2 +
 lib/librte_mempool/rte_mempool_version.map |  18 
 lib/librte_meter/Makefile  |   2 +
 lib/librte_meter/rte_meter_version.map |  13 +++
 lib/librte_pipeline/Makefile   |   2 +
 lib/librte_pipeline/rte_pipeline_version.map   |  23 +
 lib/librte_pmd_af_packet/Makefile  |   2 +
 .../rte_pmd_af_packet_version.map  |   7 ++
 lib/librte_pmd_bond/Makefile   |   2 +
 lib/librte_pmd_bond/rte_eth_bond_version.map   |  21 
 lib/librte_pmd_e1000/Makefile  |   2 +
 lib/librte_pmd_e1000/rte_pmd_e1000_version.map |   5 +
 lib/librte_pmd_enic/Makefile   |   2 +
 lib/librte_pmd_enic/rte_pmd_enic_version.map   |   5 +
 lib/librte_pmd_i40e/Makefile   |   2 +
 lib/librte_pmd_i40e/rte_pmd_i40e_version.map   |   5 +
 lib/librte_pmd_ixgbe/Makefile  |   2 +
 lib/librte_pmd_ixgbe/rte_pmd_ixgbe_version.map |   5 +
 lib/librte_pmd_pcap/Makefile   |   2 +
 lib/librte_pmd_pcap/rte_pmd_pcap_version.map   |   5 +
 lib/librte_pmd_ring/Makefile   |   2 +
 lib/librte_pmd_ring/rte_eth_ring.c |   2 +-
 lib/librte_pmd_ring/rte_eth_ring.h |   6 --
 lib/librte_pmd_ring/rte_eth_ring_version.map   |  10 ++
 lib/librte_pmd_virtio/Makefile |   1 +
 lib/librte_pmd_virtio/rte_pmd_virtio_version.map   |   5 +
 lib/librte_pmd_vmxnet3/Makefile|   2 +
 lib/librte_pmd_vmxnet3/rte_pmd_vmxnet3_version.map |   5 +
 lib/librte_pmd_xenvirt/Makefile|   2 +
 lib/librte_pmd_xenvirt/rte_eth_xenvirt_version.map |   8 ++
 lib/librte_port/Makefile   |   2 +
 lib/librte_port/rte_port_version.map   |  18 
 lib/librte_power/Makefile  |   2 +
 lib/librte_power/rte_power_version.map |  18 
 lib/librte_ring/Makefile   |   2 +
 lib/librte_ring/rte_ring_version.map   |  12 +++
 lib/librte_sched/Makefile  |   2 +
 lib/librte_sched/rte_sched_version.map |  22 
 lib/librte_table/Makefile  |   2 +
 lib/librte_table/rte_table_version.map |  22 
 lib/librte_timer/Makefile  |   2 +
 lib/librte_timer/rte_timer_version.map |  16 +++
 lib/librte_vhost/Makefile  |   2 +
 lib/librte_vhost/rte_vhost_version.map |  14 +++
 74 files changed, 874 insertions(+), 7 deletions(-)
 create mode 100644 lib/librte_acl/rte_acl_version.map
 create mode 100644 lib/librte_cfgfile/rte_cfg

[dpdk-dev] [PATCH v4 1/4] compat: Add infrastructure to support symbol versioning

[Neil Horman]

Add initial pass header files to support symbol versioning.

Signed-off-by: Neil Horman 
CC: Thomas Monjalon 
CC: "Richardson, Bruce" 
CC: "Gonzalez Monroy, Sergio" 

---
Change Notes:
V2)
Moved ifeq to _INSTALL target

V3)
Undo V2 changes and make librte_compat use the rte.install.mk file
instead

v4)
changed --version-script to accept SRCDIR in this patch at per request
documented versioning macros
cleaned up macro parameter consistency
converted SA macro to RTE_STR macro
fixed copyright
---
 lib/Makefile   |   1 +
 lib/librte_compat/Makefile |  38 +
 lib/librte_compat/rte_compat.h | 117 +
 mk/rte.lib.mk  |   4 ++
 4 files changed, 160 insertions(+)
 create mode 100644 lib/librte_compat/Makefile
 create mode 100644 lib/librte_compat/rte_compat.h

diff --git a/lib/Makefile b/lib/Makefile
index 0ffc982..d617d81 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -31,6 +31,7 @@

 include $(RTE_SDK)/mk/rte.vars.mk

+DIRS-y += librte_compat
 DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
 DIRS-$(CONFIG_RTE_LIBRTE_MALLOC) += librte_malloc
 DIRS-$(CONFIG_RTE_LIBRTE_RING) += librte_ring
diff --git a/lib/librte_compat/Makefile b/lib/librte_compat/Makefile
new file mode 100644
index 000..0bab870
--- /dev/null
+++ b/lib/librte_compat/Makefile
@@ -0,0 +1,38 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2013 Neil Horman 
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+
+# install includes
+SYMLINK-y-include := rte_compat.h
+
+include $(RTE_SDK)/mk/rte.install.mk
diff --git a/lib/librte_compat/rte_compat.h b/lib/librte_compat/rte_compat.h
new file mode 100644
index 000..d7cc176
--- /dev/null
+++ b/lib/librte_compat/rte_compat.h
@@ -0,0 +1,117 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010 Neil Horman .
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF TH

[dpdk-dev] [PATCH] rte_log: remove unnecessary stubs

[Thomas Monjalon]

> The read/seek/close stub functions are unnecessary on the
> log stream.  Per glibc fopencookie man page:
> 
>cookie_read_function_t *read
>   If *read is a null pointer, then reads from  the  custom  stream
>   always return end of file.
> 
>cookie_seek_function_t *seek
>   If *seek is a null pointer, then it is not possible  to  perform
>   seek operations on the stream.
> 
>cookie_close_function_t *close
>   If  *close is NULL, then no special action is performed when the
>   stream is closed.
> 
> Signed-off-by: Stephen Hemminger 

Acked-by: Thomas Monjalon 

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH RFC] eal_memory: Search only DPDK hugetlbfs maps

[Thomas Monjalon]

> When scanning the hugetlbfs maps search only for the DPDK maps.
> This will allow the application create its own hugetlbfs mappings
> and use the DPDK facilities on the same hugetlbfs mount point.
> 
> Signed-off-by: Vlad Zolotarov 

Acked-by: Thomas Monjalon 

It is a RFC patch but there is no comment, so
Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] ethdev: fix missing parenthesis

[Thomas Monjalon]

2015-01-09 16:05, Michal Jastrzebski:
> Signed-off-by: Pawel Wodkowski 

Good catch!
Was introduced in commit 4bdefaade6d1 (VMDQ enhancements).
Note that quite often, when a patch contains too much things,
we miss this kind of bugs. That's a reason to well split patches.

Acked-by: Thomas Monjalon 

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH v2] Fix rte_is_power_of_2

[Thomas Monjalon]

> > rte_is_power_of_2 returns true for 0 and 0 is not power_of_2. Fix
> > by checking for n.
> > 
> > Signed-off-by: Ravi Kerur 
> Acked-by: Neil Horman 

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] rte.app.mk: whole-archive should be used with COMBINED_LIB

[Thomas Monjalon]

2015-01-02 14:58, Neil Horman:
> When building static archives with CONFIG_COMBINED_LIBS, we still need to
> specify --whole-archive to pull in all the proper constructors.
> 
> Signed-off-by: Neil Horman 
> Reported-by: Lyn M 
> Tested-by: Lyn M 
> CC: Lyn M 
> CC: Thomas Monjalon 

Acked-by: Thomas Monjalon 

Applied

Thanks
-- 
Thomas

[dpdk-dev] Why nothing since 1.8.0?

[Neil Horman]

On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
> 2015-01-15 08:06, Neil Horman:
> > On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote:
> > > 2015-01-15 04:27, Ouyang, Changchun:
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > > > > > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger wrote:
> > > > > > > Ok, so 1.8.0 came out almost a month ago and none of the patches
> > > > > > > that were deferred waiting for the release got merged since then.
> > > > > > > Last commit in git is the 1.8.0 release.
> > > > > > >
> > > > > > > Where is the post-merge window bundle, where are the later 
> > > > > > > commits?
> > > > > > > Lots of patches are sitting rotting in patchwork...
> > > > > >
> > > > > > +1, I've had the same questions.
> > > > > > Neil
> > > > > 
> > > > > +1, Some patch set might be ready for being merged.
> > > > 
> > > > +1,  the earlier some patches are merged into mainline, and the easier 
> > > > those
> > > > sequent patch sets can resolve their conflicts.
> > > 
> > > +1, there are some patches which are properly reviewed
> > > 
> > > Reminder: sub-tree to manage specific part of DPDK can be open on request
> > 
> > Ok, I think what you're saying here is you're too busy to handle all the 
> > patches
> > comming in at the moment.  As such I'd like to propose a sub-tree 
> > encompassing
> > all the pmds in DPDK.  I would envision that including all the acutal pmd's 
> > in
> > the tree, as well as the infrastructure that is used to interface them to 
> > the
> > core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the patch 
> > pool
> > and send you pull requests.
> 
> The list of PMDs is increasing:
>   librte_pmd_af_packet
>   librte_pmd_bond
>   librte_pmd_e1000
>   librte_pmd_enic
>   librte_pmd_i40e
>   librte_pmd_ixgbe
>   librte_pmd_pcap
>   librte_pmd_ring
>   librte_pmd_virtio
>   librte_pmd_vmxnet3
>   librte_pmd_xenvirt
> There is already some sub-trees for bnx2x, fm10k and i40e:
>   http://dpdk.org/browse/
> 
Yes, and I've mentioned before that that is an absolutely silly way to break out
subtrees.  You have to find a balance of workload distribution and developer
convienience.

I also note that these are problematic because you're not merging anything
from them. Is it your intention to keep bnx2 and fm10k separate in perpituity?
If so, thats a real problem, because then we effectively just have several out
of tree drivers, and thats just unacceptible.

> > If you could set me up with a login to dpdk.org, I'd appreciate it.
> 
> It is preferred to have 1 sub-tree per module.
> What do you think of managing contributions for af_packet and/or virtio?
> It would make sense as virtio is a RedHat technology.
> Maybe it could include vhost lib and example.
> 
No, for reasons I've mentioned before.  If you take each pmd/library and create
a subtree for it, you've created the most fine grained control of subtrees you
could ask for, but you've created a nighmare of a burden on developers who want
to update any code, especially if they have patches that hit multiple trees.

Look at some of the stats in the dpdk tree:

Library Commits between 1.7.0 and 1.8.0
librte_acl  5
librte_cfgfile  0
librte_cmdline  4
librte_compat   0
librte_distributor  5
librte_eal  125
librte_ether31
librte_hash 1
librte_ip_frag  5
librte_ivshmem  0
librte_kni  2
librte_kvargs   0
librte_lpm  1
librte_malloc   1
librte_mbuf 39
librte_mempool  4
librte_meter0
librte_net  4
librte_pipeline 0
librte_pmd_af_packet4
librte_pmd_bond 20
librte_pmd_e100021
librte_pmd_enic 12
librte_pmd_i40e 90
librte_pmd_ixgbe83
librte_pmd_pcap 4
librte_pmd_ring 0
librte_pmd_virtio   21
librte_pmd_vmxnet3  21
librte_pmd_xenvirt  6
librte_port 6
librte_power3
librte_ring 2
librte_sched1
librte_table7
librte_timer0
librte_vhost30

If you look at all of the pmds in the dpdk tree, we're talking about ~300
patches per release.  If you look at the net-next tree for the linux kernel,
Dave Miller merged 569 patches on his own (based on the following command:
git log --pretty=format:%H v3.17..v3.18 -- drivers/net/ethernet/ net/core/ | wc
-l)

And that doesn't account for the ~500 patches that come in via pull request from
the wireless subtree.  Nor does it account for the merge window for net-next
being 2 months instead of dpdk's 6 months.  Theres no need in any way for 12
maintainers to be twiddling their thumbs waiting on ~20 patches each, and for
that split, you've forced developers to poten

[dpdk-dev] [PATCH v6] VFIO: Avoid to enable vfio while the module not loaded

[Burakov, Anatoly]

Yep, apologies, it's my fault as it was my suggestion. I knew there was a 
linuxapp-only EAL header, for some reason I thought it's eal_private. Any 
suggestions on where to put this function? I don't think BSD needs this 
function. 

Thanks,
Anatoly

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, January 15, 2015 1:38 PM
> To: Qiu, Michael
> Cc: Burakov, Anatoly; dev at dpdk.org; Xie, Huawei
> Subject: Re: [PATCH v6] VFIO: Avoid to enable vfio while the module not
> loaded
> 
> > > When vfio module is not loaded when kernel support vfio feature, the
> > > routine still try to open the container to get file description.
> > >
> > > This action is not safe, and of cause got error messages:
> > >
> > > EAL: Detected 40 lcore(s)
> > > EAL:   unsupported IOMMU type!
> > > EAL: VFIO support could not be initialized
> > > EAL: Setting up memory...
> > >
> > > This may make user confuse, this patch make it reasonable and much
> > > more soomth to user.
> > >
> > > Signed-off-by: Michael Qiu 
> >
> > Acked-by: Anatoly Burakov 
> 
> Note that rte_eal_check_module has no bsd counterpart.
> It could be needed later.
> 
> Applied
> 
> Thanks
> --
> Thomas

[dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine

[Ananyev, Konstantin]

Hi lads,

> -Original Message-
> From: Liu, Jijiang
> Sent: Wednesday, January 14, 2015 3:01 AM
> To: Olivier MATZ
> Cc: dev at dpdk.org; Ananyev, Konstantin
> Subject: RE: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum 
> forwarding engine
> 
> Hi Olivier,
> 
> > -Original Message-
> > From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> > Sent: Tuesday, January 13, 2015 5:56 PM
> > To: Liu, Jijiang
> > Cc: dev at dpdk.org; Ananyev, Konstantin
> > Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and
> > csum forwarding engine
> >
> > Hi Jijiang,
> >
> > On 01/13/2015 04:04 AM, Liu, Jijiang wrote:
> > > the following two commands are.
> > >
> > > 1. tx_checksum set sw-tunnel-mode on/off
> > >
> > > 2. tx_checksum set hw-tunnel-mode on/off
> > >
> > > For command 1, If the sw-tunnel-mode is set/clear, which will
> > > set/clear a testpmd flag that is used in the process of analyzing
> > > incoming packet., the pseudo-codes are list below,
> > >
> > > If (sw-tunnel-mode)
> > >
> > >   Csum fwd engine will analyze if incoming packet is a tunneling packet.
> > > tunnel = 1;
> > > else
> > > Csum fwd engine will not analyze if incoming packet is a 
> > > tunneling
> > packet, and treat all the incoming packets as non-tunneling packets.
> > > It is used for A.
> >
> > What about "recognize-tunnel" instead of "sw-tunnel-mode"?
> > Or "parse-tunnel"?
> 
> Ok,  "parse-tunnel" or "parse-tunnel-pkt" is better.
> Thanks.
> 
> 
> > To me, using "sw-" or "hw-" prefix is confusing because in any case the 
> > checksums
> > can be calculated in software or hardware depending on "tx_checksum set 
> > outer-
> > ip hw|sw".
> >
> > Moreover, this command has an impact on receive side, but the name is still
> > "tx_checksum". Maybe this is also confusing.
> Ok,  how about this?
> 
> set  checksum parse-tunnel-pkt on|off  (port-id)
> 
> > > For command 2, If the hw-tunnel-mode is set/clear, which will
> > > set/clear a testpmd flag that is used in the process of how to handle
> > > tunneling packet, the pseudo-codes are list below,
> > >
> > > if (tunnel == 1) { // this is a tunneling packet
> > >  If (hw-tunnel-mode)
> > >ol_flags |= PKT_TX_UDP_TUNNEL_PKT;
> > >
> > >  Csum fwd engine set PKT_TX_UDP_TUNNEL_PKT offload flag, which
> > means to tell HW treat  the transmit packet as a tunneling packet to do 
> > checksum
> > offload.
> > >  It is used for B.1
> > > Else
> > >Csum fwd engine doesn't  set PKT_TX_UDP_TUNNEL_PKT 
> > > offload
> > flag, which means  tell HW to treat the packet as ordinary (non-tunnelled) 
> > packet.
> > > It is used for B.2
> > > }
> >
> > What about:
> >tx_checksum set tunnel-method normal|outer
> > It would select if we use lX_len or outer_lX_len. Is it what you mean?
> 
> tx_checksum set tunnel-method normal|outer
> 
> Let me explain that what differences of  TX checksum mechanism between 
> ixgbe(82599) and i40e(40G NIC) are.
> 
> For 82599, there is only one register that is used for L3 checksum offload. 
> So for tunneling packet, hardware is unable to recognize the
> packet is tunneling packet and  the register cannot be worked for both outer 
> L3 checksum offload and inner L3 checksum offload at the
> same time,  just for outer or inner.
> 
> For i40e(40G NIC),  there are two registers that are user for L3 TX checksum 
> offload, so for tunneling packet, the outer and inner L3
> checksum offload  can be done by hardware at the same time, but a 
> prerequisite is that we must tell
> Hardware the packet is a tunneling packet by setting a register 
> (PKT_TX_UDP_TUNNEL_PKT offload flag is used to indicate to set this
> register.)
> 
> As for other NIC, I think its working mechanism should be same as the i40e if 
> it can recognize tunneling packet.
> 
> So my idea:
> tx_checksum set tunnel-method  tunnel-pkt on|off
> 
> or
> tx_checksum set tunnel-pkt on|off
> 
> What do you think?
> 
> 
> > And this only makes sense when we use hw checksum right?
> yes
> 
> >
> > >> And will it be possible to support future hardware that will be able
> > >> to compute both outer l3, outer l4, l3 and l4 checksums?
> 
> Currently, if outer l4  will be supported in the future, and we can add 
> outer-udp/tcp option into following command.
> Tx_checksum set outer-ip|ip|sctp|udp|tcp.
> 
> 
> > > Yes.
> > > Currently, i40e support outer l3, outer l4, l3 and l4 checksums offload 
> > > at the
> > same time.
> Sorry, my bad.
> I40e just support outer l3, l3 and l4.
> 
> Fortville can offload the following L3 and L4 integrity checks: IPv4 
> header(s) checksum for "simple" and tunneled packets, Inner TCP or
> UDP checksum and SCTP CRC integrity. Tunneling UDP headers and GRE header are 
> not offloaded while Fortville leaves their checksum
> field as is. If a checksum is required, software should provide it as well as 
> the in

[dpdk-dev] [PATCH 22/22] virtio: Use soft vlan strip in mergeable Rx path

[Ouyang Changchun]

To keep the consistent logic with normal Rx path, the mergeable
Rx path also needs software vlan strip/decap if it is enabled.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_rxtx.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
b/lib/librte_pmd_virtio/virtio_rxtx.c
index 2529dc4..9090613 100644
--- a/lib/librte_pmd_virtio/virtio_rxtx.c
+++ b/lib/librte_pmd_virtio/virtio_rxtx.c
@@ -568,6 +568,7 @@ virtio_recv_mergeable_pkts(void *rx_queue,
uint16_t nb_pkts)
 {
struct virtqueue *rxvq = rx_queue;
+   struct virtio_hw *hw = rxvq->hw;
struct rte_mbuf *rxm, *new_mbuf;
uint16_t nb_used, num, nb_rx = 0;
uint32_t len[VIRTIO_MBUF_BURST_SZ];
@@ -674,6 +675,9 @@ virtio_recv_mergeable_pkts(void *rx_queue,
seg_res -= rcv_cnt;
}

+   if (hw->vlan_strip)
+   rte_vlan_strip(rx_pkts[nb_rx]);
+
VIRTIO_DUMP_PACKET(rx_pkts[nb_rx],
rx_pkts[nb_rx]->data_len);

-- 
1.8.4.2

[dpdk-dev] [PATCH 21/22] example/vhost: Add vlan-strip cmd line option

[Ouyang Changchun]

Support turn on/off RX VLAN strip on host, this let guest get the chance of
using its software VALN strip functionality.

Signed-off-by: Changchun Ouyang 
---
 examples/vhost/main.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index a7e623e..4df4977 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -178,6 +178,9 @@ static uint32_t num_devices;
 static uint32_t zero_copy;
 static int mergeable;

+/* Do vlan strip on host, enabled on default */
+static uint32_t vlan_strip = 1;
+
 /* number of descriptors to apply*/
 static uint32_t num_rx_descriptor = RTE_TEST_RX_DESC_DEFAULT_ZCP;
 static uint32_t num_tx_descriptor = RTE_TEST_TX_DESC_DEFAULT_ZCP;
@@ -570,6 +573,7 @@ us_vhost_usage(const char *prgname)
"   --rx-retry-delay [0-N]: timeout(in usecond) between 
retries on RX. This makes effect only if retries on rx enabled\n"
"   --rx-retry-num [0-N]: the number of retries on rx. This 
makes effect only if retries on rx enabled\n"
"   --mergeable [0|1]: disable(default)/enable RX mergeable 
buffers\n"
+   "   --vlan-strip [0|1]: disable/enable(default) RX VLAN 
strip on host\n"
"   --stats [0-N]: 0: Disable stats, N: Time in seconds to 
print stats\n"
"   --dev-basename: The basename to be used for the 
character device.\n"
"   --zero-copy [0|1]: disable(default)/enable rx/tx "
@@ -597,6 +601,7 @@ us_vhost_parse_args(int argc, char **argv)
{"rx-retry-delay", required_argument, NULL, 0},
{"rx-retry-num", required_argument, NULL, 0},
{"mergeable", required_argument, NULL, 0},
+   {"vlan-strip", required_argument, NULL, 0},
{"stats", required_argument, NULL, 0},
{"dev-basename", required_argument, NULL, 0},
{"zero-copy", required_argument, NULL, 0},
@@ -697,6 +702,22 @@ us_vhost_parse_args(int argc, char **argv)
}
}

+   /* Enable/disable RX VLAN strip on host. */
+   if (!strncmp(long_option[option_index].name,
+   "vlan-strip", MAX_LONG_OPT_SZ)) {
+   ret = parse_num_opt(optarg, 1);
+   if (ret == -1) {
+   RTE_LOG(INFO, VHOST_CONFIG,
+   "Invalid argument for VLAN 
strip [0|1]\n");
+   us_vhost_usage(prgname);
+   return -1;
+   } else {
+   vlan_strip = !!ret;
+   vmdq_conf_default.rxmode.hw_vlan_strip =
+   vlan_strip;
+   }
+   }
+
/* Enable/disable stats. */
if (!strncmp(long_option[option_index].name, "stats", 
MAX_LONG_OPT_SZ)) {
ret = parse_num_opt(optarg, INT32_MAX);
@@ -955,7 +976,9 @@ link_vmdq(struct vhost_dev *vdev, struct rte_mbuf *m)
dev->device_fh);

/* Enable stripping of the vlan tag as we handle routing. */
-   rte_eth_dev_set_vlan_strip_on_queue(ports[0], 
(uint16_t)vdev->vmdq_rx_q, 1);
+   if (vlan_strip)
+   rte_eth_dev_set_vlan_strip_on_queue(ports[0],
+   (uint16_t)vdev->vmdq_rx_q, 1);

/* Set device as ready for RX. */
vdev->ready = DEVICE_RX;
-- 
1.8.4.2

[dpdk-dev] [PATCH 20/22] example/vhost: Avoid inserting vlan twice

[Ouyang Changchun]

Check if it has already been vlan-tagged packet, if true, avoid inserting a
duplicated vlan tag into it.

This is a possible case when guest has the capability of inserting vlan tag.

Signed-off-by: Changchun Ouyang 
---
 examples/vhost/main.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 1f1edbe..a7e623e 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -1120,6 +1120,7 @@ virtio_tx_route(struct vhost_dev *vdev, struct rte_mbuf 
*m, uint16_t vlan_tag)
unsigned len, ret, offset = 0;
const uint16_t lcore_id = rte_lcore_id();
struct virtio_net *dev = vdev->dev;
+   struct ether_hdr *nh;

/*check if destination is local VM*/
if ((vm2vm_mode == VM2VM_SOFTWARE) && (virtio_tx_local(vdev, m) == 0)) {
@@ -1141,12 +1142,21 @@ virtio_tx_route(struct vhost_dev *vdev, struct rte_mbuf 
*m, uint16_t vlan_tag)
tx_q = &lcore_tx_queue[lcore_id];
len = tx_q->len;

-   m->ol_flags = PKT_TX_VLAN_PKT;
+   nh = rte_pktmbuf_mtod(m, struct ether_hdr *);
+   if (unlikely(nh->ether_type == rte_cpu_to_be_16(ETHER_TYPE_VLAN))) {
+   /* Guest has inserted the vlan tag. */
+   struct vlan_hdr *vh = (struct vlan_hdr *) (nh + 1);
+   uint16_t vlan_tag_be = rte_cpu_to_be_16(vlan_tag);
+   if (vh->vlan_tci != vlan_tag_be)
+   vh->vlan_tci = vlan_tag_be;
+   } else {
+   m->ol_flags = PKT_TX_VLAN_PKT;

-   m->data_len += offset;
-   m->pkt_len += offset;
+   m->data_len += offset;
+   m->pkt_len += offset;

-   m->vlan_tci = vlan_tag;
+   m->vlan_tci = vlan_tag;
+   }

tx_q->m_table[len] = m;
len++;
-- 
1.8.4.2

[dpdk-dev] [PATCH 19/22] ether: Fix vlan strip/insert issue

[Ouyang Changchun]

Need swap the data from cpu to BE(big endian) for vlan-type.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_ether/rte_ether.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ether/rte_ether.h b/lib/librte_ether/rte_ether.h
index 3b6ab4b..90fb3c9 100644
--- a/lib/librte_ether/rte_ether.h
+++ b/lib/librte_ether/rte_ether.h
@@ -350,7 +350,7 @@ static inline int rte_vlan_strip(struct rte_mbuf *m)
struct ether_hdr *eh
 = rte_pktmbuf_mtod(m, struct ether_hdr *);

-   if (eh->ether_type != ETHER_TYPE_VLAN)
+   if (eh->ether_type != rte_cpu_to_be_16(ETHER_TYPE_VLAN))
return -1;

struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
@@ -400,7 +400,7 @@ static inline int rte_vlan_insert(struct rte_mbuf **m)
return -ENOSPC;

memmove(nh, oh, 2 * ETHER_ADDR_LEN);
-   nh->ether_type = ETHER_TYPE_VLAN;
+   nh->ether_type = rte_cpu_to_be_16(ETHER_TYPE_VLAN);

vh = (struct vlan_hdr *) (nh + 1);
vh->vlan_tci = rte_cpu_to_be_16((*m)->vlan_tci);
-- 
1.8.4.2

[dpdk-dev] [PATCH 18/22] virtio: Fix descriptor index issue

[Ouyang Changchun]

It should use vring descriptor index instead of used_ring index to index 
vq_descx.

Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_rxtx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
b/lib/librte_pmd_virtio/virtio_rxtx.c
index 12c2310..2529dc4 100644
--- a/lib/librte_pmd_virtio/virtio_rxtx.c
+++ b/lib/librte_pmd_virtio/virtio_rxtx.c
@@ -144,9 +144,9 @@ virtio_xmit_cleanup(struct virtqueue *vq, uint16_t num)

used_idx = (uint16_t)(vq->vq_used_cons_idx & (vq->vq_nentries - 
1));
uep = &vq->vq_ring.used->ring[used_idx];
-   dxp = &vq->vq_descx[used_idx];

desc_idx = (uint16_t) uep->id;
+   dxp = &vq->vq_descx[desc_idx];
vq->vq_used_cons_idx++;
vq_ring_free_chain(vq, desc_idx);

-- 
1.8.4.2

[dpdk-dev] [PATCH 17/22] virtio: Use port IO to get PCI resource.

[Ouyang Changchun]

Make virtio not require UIO for some security reasons, this is to match 6Wind's 
virtio-net-pmd.

Signed-off-by: Changchun Ouyang 
---
 config/common_linuxapp  |  2 +
 lib/librte_eal/common/include/rte_pci.h |  4 ++
 lib/librte_eal/linuxapp/eal/eal_pci.c   |  5 +-
 lib/librte_pmd_virtio/virtio_ethdev.c   | 91 -
 4 files changed, 100 insertions(+), 2 deletions(-)

diff --git a/config/common_linuxapp b/config/common_linuxapp
index 6243d4b..a3227a2 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -125,6 +125,8 @@ CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
 CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
 CONFIG_RTE_EAL_IGB_UIO=y
 CONFIG_RTE_EAL_VFIO=y
+# Only for VIRTIO PMD currently
+CONFIG_RTE_EAL_PORT_IO=n

 #
 # Special configurations in PCI Config Space for high performance
diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index 66ed793..19abc1f 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -193,6 +193,10 @@ struct rte_pci_driver {

 /** Device needs PCI BAR mapping (done with either IGB_UIO or VFIO) */
 #define RTE_PCI_DRV_NEED_MAPPING 0x0001
+/** Device needs port IO(done with /proc/ioports) */
+#ifdef RTE_EAL_PORT_IO
+#define RTE_PCI_DRV_PORT_IO 0x0002
+#endif
 /** Device driver must be registered several times until failure - deprecated 
*/
 #pragma GCC poison RTE_PCI_DRV_MULTIPLE
 /** Device needs to be unbound even if no module is provided */
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index b5f5410..5db0059 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -574,7 +574,10 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr, 
struct rte_pci_device *d
/* map resources for devices that use igb_uio */
ret = pci_map_device(dev);
if (ret != 0)
-   return ret;
+#ifdef RTE_EAL_PORT_IO
+   if ((dr->drv_flags & RTE_PCI_DRV_PORT_IO) == 0)
+#endif
+   return ret;
} else if (dr->drv_flags & RTE_PCI_DRV_FORCE_UNBIND &&
   rte_eal_process_type() == RTE_PROC_PRIMARY) {
/* unbind current driver */
diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index 1ec29e1..15324c9 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -961,6 +961,71 @@ static int virtio_resource_init(struct rte_pci_device 
*pci_dev)
 start, size);
return 0;
 }
+
+#ifdef RTE_EAL_PORT_IO
+/* Extract port I/O numbers from proc/ioports */
+static int virtio_resource_init_by_portio(struct rte_pci_device *pci_dev)
+{
+   uint16_t start, end;
+   int size;
+   FILE *fp;
+   char *line = NULL;
+   char pci_id[16];
+   int found = 0;
+   size_t linesz;
+
+   snprintf(pci_id, sizeof(pci_id), PCI_PRI_FMT,
+pci_dev->addr.domain,
+pci_dev->addr.bus,
+pci_dev->addr.devid,
+pci_dev->addr.function);
+
+   fp = fopen("/proc/ioports", "r");
+   if (fp == NULL) {
+   PMD_INIT_LOG(ERR, "%s(): can't open ioports", __func__);
+   return -1;
+   }
+
+   while (getdelim(&line, &linesz, '\n', fp) > 0) {
+   char *ptr = line;
+   char *left;
+   int n;
+
+   n = strcspn(ptr, ":");
+   ptr[n] = 0;
+   left = &ptr[n+1];
+
+   while (*left && isspace(*left))
+   left++;
+
+   if (!strncmp(left, pci_id, strlen(pci_id))) {
+   found = 1;
+
+   while (*ptr && isspace(*ptr))
+   ptr++;
+
+   sscanf(ptr, "%04hx-%04hx", &start, &end);
+   size = end - start + 1;
+
+   break;
+   }
+   }
+
+   free(line);
+   fclose(fp);
+
+   if (!found)
+   return -1;
+
+   pci_dev->mem_resource[0].addr = (void *)(uintptr_t)(uint32_t)start;
+   pci_dev->mem_resource[0].len =  (uint64_t)size;
+   PMD_INIT_LOG(DEBUG,
+"PCI Port IO found start=0x%lx with size=0x%lx",
+start, size);
+   return 0;
+}
+#endif
+
 #else
 static int
 virtio_has_msix(const struct rte_pci_addr *loc __rte_unused)
@@ -974,6 +1039,14 @@ static int virtio_resource_init(struct rte_pci_device 
*pci_dev __rte_unused)
/* no setup required */
return 0;
 }
+
+#ifdef RTE_EAL_PORT_IO
+static int virtio_resource_init_by_portio(struct rte_pci_device *pci_dev)
+{
+   /* no setup required */
+   return 0;
+}
+#endif
 #endif

 /*
@@ -1039,7 +1112,10 @@ eth_virti

[dpdk-dev] [PATCH 16/22] virtio: Free mbuf's with threshold

[Ouyang Changchun]

This makes virtio driver work like ixgbe. Transmit buffers are
held until a transmit threshold is reached. The previous behavior
was to hold mbuf's until the ring entry was reused which caused
more memory usage than needed.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c |  7 ++--
 lib/librte_pmd_virtio/virtio_rxtx.c   | 75 +--
 lib/librte_pmd_virtio/virtqueue.h |  3 +-
 3 files changed, 60 insertions(+), 25 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index c5f21c1..1ec29e1 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -176,15 +176,16 @@ virtio_send_command(struct virtqueue *vq, struct 
virtio_pmd_ctrl *ctrl,

virtqueue_notify(vq);

-   while (vq->vq_used_cons_idx == vq->vq_ring.used->idx)
+   rte_rmb();
+   while (vq->vq_used_cons_idx == vq->vq_ring.used->idx) {
+   rte_rmb();
usleep(100);
+   }

while (vq->vq_used_cons_idx != vq->vq_ring.used->idx) {
uint32_t idx, desc_idx, used_idx;
struct vring_used_elem *uep;

-   virtio_rmb();
-
used_idx = (uint32_t)(vq->vq_used_cons_idx
& (vq->vq_nentries - 1));
uep = &vq->vq_ring.used->ring[used_idx];
diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
b/lib/librte_pmd_virtio/virtio_rxtx.c
index b44f091..12c2310 100644
--- a/lib/librte_pmd_virtio/virtio_rxtx.c
+++ b/lib/librte_pmd_virtio/virtio_rxtx.c
@@ -129,17 +129,32 @@ virtqueue_dequeue_burst_rx(struct virtqueue *vq, struct 
rte_mbuf **rx_pkts,
return i;
 }

+#ifndef DEFAULT_TX_FREE_THRESH
+#define DEFAULT_TX_FREE_THRESH 32
+#endif
+
+/* Cleanup from completed transmits. */
 static void
-virtqueue_dequeue_pkt_tx(struct virtqueue *vq)
+virtio_xmit_cleanup(struct virtqueue *vq, uint16_t num)
 {
-   struct vring_used_elem *uep;
-   uint16_t used_idx, desc_idx;
+   uint16_t i, used_idx, desc_idx;
+   for (i = 0; i < num; i++) {
+   struct vring_used_elem *uep;
+   struct vq_desc_extra *dxp;
+
+   used_idx = (uint16_t)(vq->vq_used_cons_idx & (vq->vq_nentries - 
1));
+   uep = &vq->vq_ring.used->ring[used_idx];
+   dxp = &vq->vq_descx[used_idx];
+
+   desc_idx = (uint16_t) uep->id;
+   vq->vq_used_cons_idx++;
+   vq_ring_free_chain(vq, desc_idx);

-   used_idx = (uint16_t)(vq->vq_used_cons_idx & (vq->vq_nentries - 1));
-   uep = &vq->vq_ring.used->ring[used_idx];
-   desc_idx = (uint16_t) uep->id;
-   vq->vq_used_cons_idx++;
-   vq_ring_free_chain(vq, desc_idx);
+   if (dxp->cookie != NULL) {
+   rte_pktmbuf_free(dxp->cookie);
+   dxp->cookie = NULL;
+   }
+   }
 }


@@ -203,8 +218,6 @@ virtqueue_enqueue_xmit(struct virtqueue *txvq, struct 
rte_mbuf *cookie)

idx = head_idx;
dxp = &txvq->vq_descx[idx];
-   if (dxp->cookie != NULL)
-   rte_pktmbuf_free(dxp->cookie);
dxp->cookie = (void *)cookie;
dxp->ndescs = needed;

@@ -404,6 +417,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
 {
uint8_t vtpci_queue_idx = 2 * queue_idx + VTNET_SQ_TQ_QUEUE_IDX;
struct virtqueue *vq;
+   uint16_t tx_free_thresh;
int ret;

PMD_INIT_FUNC_TRACE();
@@ -421,6 +435,22 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
return ret;
}

+   tx_free_thresh = tx_conf->tx_free_thresh;
+   if (tx_free_thresh == 0)
+   tx_free_thresh =
+   RTE_MIN(vq->vq_nentries / 4, DEFAULT_TX_FREE_THRESH);
+
+   if (tx_free_thresh >= (vq->vq_nentries - 3)) {
+   RTE_LOG(ERR, PMD, "tx_free_thresh must be less than the "
+   "number of TX entries minus 3 (%u)."
+   " (tx_free_thresh=%u port=%u queue=%u)\n",
+   vq->vq_nentries - 3,
+   tx_free_thresh, dev->data->port_id, queue_idx);
+   return -EINVAL;
+   }
+
+   vq->vq_free_thresh = tx_free_thresh;
+
dev->data->tx_queues[queue_idx] = vq;
return 0;
 }
@@ -688,11 +718,9 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts, uint16_t nb_pkts)
 {
struct virtqueue *txvq = tx_queue;
struct rte_mbuf *txm;
-   uint16_t nb_used, nb_tx, num;
+   uint16_t nb_used, nb_tx;
int error;

-   nb_tx = 0;
-
if (unlikely(nb_pkts < 1))
return nb_pkts;

@@ -700,21 +728,26 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts, uint16_t nb_pkts)
nb_used = VIRTQUEUE_NUSED(txvq);

virtio_rmb();
+   if (likely(nb_used > txvq->vq_free_thresh))
+   virtio_xmit_cleanup(txv

[dpdk-dev] [PATCH 15/22] virtio: Add ability to set MAC address

[Ouyang Changchun]

Need to have do special things to set default mac address.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_ether/rte_ethdev.h |  5 +
 lib/librte_pmd_virtio/virtio_ethdev.c | 24 
 2 files changed, 29 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 07d55b8..cbe3fdf 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1249,6 +1249,10 @@ typedef void (*eth_mac_addr_add_t)(struct rte_eth_dev 
*dev,
  uint32_t vmdq);
 /**< @internal Set a MAC address into Receive Address Address Register */

+typedef void (*eth_mac_addr_set_t)(struct rte_eth_dev *dev,
+ struct ether_addr *mac_addr);
+/**< @internal Set a MAC address into Receive Address Address Register */
+
 typedef int (*eth_uc_hash_table_set_t)(struct rte_eth_dev *dev,
  struct ether_addr *mac_addr,
  uint8_t on);
@@ -1482,6 +1486,7 @@ struct eth_dev_ops {
priority_flow_ctrl_set_t   priority_flow_ctrl_set; /**< Setup priority 
flow control.*/
eth_mac_addr_remove_t  mac_addr_remove; /**< Remove MAC address */
eth_mac_addr_add_t mac_addr_add;  /**< Add a MAC address */
+   eth_mac_addr_set_t mac_addr_set;  /**< Set a MAC address */
eth_uc_hash_table_set_tuc_hash_table_set;  /**< Set Unicast Table 
Array */
eth_uc_all_hash_table_set_t uc_all_hash_table_set;  /**< Set Unicast 
hash bitmap */
eth_mirror_rule_set_t  mirror_rule_set;  /**< Add a traffic mirror 
rule.*/
diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index e469ac2..c5f21c1 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -90,6 +90,8 @@ static void virtio_mac_addr_add(struct rte_eth_dev *dev,
struct ether_addr *mac_addr,
uint32_t index, uint32_t vmdq __rte_unused);
 static void virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index);
+static void virtio_mac_addr_set(struct rte_eth_dev *dev,
+   struct ether_addr *mac_addr);

 static int virtio_dev_queue_stats_mapping_set(
__rte_unused struct rte_eth_dev *eth_dev,
@@ -518,6 +520,7 @@ static struct eth_dev_ops virtio_eth_dev_ops = {
.vlan_filter_set = virtio_vlan_filter_set,
.mac_addr_add= virtio_mac_addr_add,
.mac_addr_remove = virtio_mac_addr_remove,
+   .mac_addr_set= virtio_mac_addr_set,
 };

 static inline int
@@ -733,6 +736,27 @@ virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t 
index)
virtio_mac_table_set(hw, uc, mc);
 }

+static void
+virtio_mac_addr_set(struct rte_eth_dev *dev, struct ether_addr *mac_addr)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+
+   memcpy(hw->mac_addr, mac_addr, ETHER_ADDR_LEN);
+
+   /* Use atomic update if available */
+   if (vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_MAC_ADDR)) {
+   struct virtio_pmd_ctrl ctrl;
+   int len = ETHER_ADDR_LEN;
+
+   ctrl.hdr.class = VIRTIO_NET_CTRL_MAC;
+   ctrl.hdr.cmd = VIRTIO_NET_CTRL_MAC_ADDR_SET;
+
+   memcpy(ctrl.data, mac_addr, ETHER_ADDR_LEN);
+   virtio_send_command(hw->cvq, &ctrl, &len, 1);
+   } else if (vtpci_with_feature(hw, VIRTIO_NET_F_MAC))
+   virtio_set_hwaddr(hw);
+}
+
 static int
 virtio_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
 {
-- 
1.8.4.2

[dpdk-dev] [PATCH 14/22] virtio: Add suport for multiple mac addresses

[Ouyang Changchun]

Virtio support multiple MAC addresses.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 94 ++-
 lib/librte_pmd_virtio/virtio_ethdev.h |  3 +-
 lib/librte_pmd_virtio/virtqueue.h | 34 -
 3 files changed, 127 insertions(+), 4 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index ec5a51e..e469ac2 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -86,6 +86,10 @@ static void virtio_dev_stats_reset(struct rte_eth_dev *dev);
 static void virtio_dev_free_mbufs(struct rte_eth_dev *dev);
 static int virtio_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vlan_id, int on);
+static void virtio_mac_addr_add(struct rte_eth_dev *dev,
+   struct ether_addr *mac_addr,
+   uint32_t index, uint32_t vmdq __rte_unused);
+static void virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index);

 static int virtio_dev_queue_stats_mapping_set(
__rte_unused struct rte_eth_dev *eth_dev,
@@ -503,8 +507,6 @@ static struct eth_dev_ops virtio_eth_dev_ops = {
.stats_get   = virtio_dev_stats_get,
.stats_reset = virtio_dev_stats_reset,
.link_update = virtio_dev_link_update,
-   .mac_addr_add= NULL,
-   .mac_addr_remove = NULL,
.rx_queue_setup  = virtio_dev_rx_queue_setup,
/* meaningfull only to multiple queue */
.rx_queue_release= virtio_dev_rx_queue_release,
@@ -514,6 +516,8 @@ static struct eth_dev_ops virtio_eth_dev_ops = {
/* collect stats per queue */
.queue_stats_mapping_set = virtio_dev_queue_stats_mapping_set,
.vlan_filter_set = virtio_vlan_filter_set,
+   .mac_addr_add= virtio_mac_addr_add,
+   .mac_addr_remove = virtio_mac_addr_remove,
 };

 static inline int
@@ -644,6 +648,92 @@ virtio_get_hwaddr(struct virtio_hw *hw)
 }

 static int
+virtio_mac_table_set(struct virtio_hw *hw,
+const struct virtio_net_ctrl_mac *uc,
+const struct virtio_net_ctrl_mac *mc)
+{
+   struct virtio_pmd_ctrl ctrl;
+   int err, len[2];
+
+   ctrl.hdr.class = VIRTIO_NET_CTRL_MAC;
+   ctrl.hdr.cmd = VIRTIO_NET_CTRL_MAC_TABLE_SET;
+
+   len[0] = uc->entries * ETHER_ADDR_LEN + sizeof(uc->entries);
+   memcpy(ctrl.data, uc, len[0]);
+
+   len[1] = mc->entries * ETHER_ADDR_LEN + sizeof(mc->entries);
+   memcpy(ctrl.data + len[0], mc, len[1]);
+
+   err = virtio_send_command(hw->cvq, &ctrl, len, 2);
+   if (err != 0)
+   PMD_DRV_LOG(NOTICE, "mac table set failed: %d", err);
+
+   return err;
+}
+
+static void
+virtio_mac_addr_add(struct rte_eth_dev *dev, struct ether_addr *mac_addr,
+   uint32_t index, uint32_t vmdq __rte_unused)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   const struct ether_addr *addrs = dev->data->mac_addrs;
+   unsigned int i;
+   struct virtio_net_ctrl_mac *uc, *mc;
+
+   if (index >= VIRTIO_MAX_MAC_ADDRS) {
+   PMD_DRV_LOG(ERR, "mac address index %u out of range", index);
+   return;
+   }
+
+   uc = alloca(VIRTIO_MAX_MAC_ADDRS * ETHER_ADDR_LEN + 
sizeof(uc->entries));
+   uc->entries = 0;
+   mc = alloca(VIRTIO_MAX_MAC_ADDRS * ETHER_ADDR_LEN + 
sizeof(mc->entries));
+   mc->entries = 0;
+
+   for (i = 0; i < VIRTIO_MAX_MAC_ADDRS; i++) {
+   const struct ether_addr *addr
+   = (i == index) ? mac_addr : addrs + i;
+   struct virtio_net_ctrl_mac *tbl
+   = is_multicast_ether_addr(addr) ? mc : uc;
+
+   memcpy(&tbl->macs[tbl->entries++], addr, ETHER_ADDR_LEN);
+   }
+
+   virtio_mac_table_set(hw, uc, mc);
+}
+
+static void
+virtio_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   struct ether_addr *addrs = dev->data->mac_addrs;
+   struct virtio_net_ctrl_mac *uc, *mc;
+   unsigned int i;
+
+   if (index >= VIRTIO_MAX_MAC_ADDRS) {
+   PMD_DRV_LOG(ERR, "mac address index %u out of range", index);
+   return;
+   }
+
+   uc = alloca(VIRTIO_MAX_MAC_ADDRS * ETHER_ADDR_LEN + 
sizeof(uc->entries));
+   uc->entries = 0;
+   mc = alloca(VIRTIO_MAX_MAC_ADDRS * ETHER_ADDR_LEN + 
sizeof(mc->entries));
+   mc->entries = 0;
+
+   for (i = 0; i < VIRTIO_MAX_MAC_ADDRS; i++) {
+   struct virtio_net_ctrl_mac *tbl;
+
+   if (i == index || is_zero_ether_addr(addrs + i))
+   continue;
+
+   tbl = is_multicast_ether_addr(addrs + i) ? mc : uc;
+   memcpy(&tbl->macs[tbl->entries++], addrs + i, ETHER_

[dpdk-dev] [PATCH 13/22] virtio: Add support for vlan filtering

[Ouyang Changchun]

Virtio supports vlan filtering.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index 13feda5..ec5a51e 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -84,6 +84,8 @@ static void virtio_dev_tx_queue_release(__rte_unused void 
*txq);
 static void virtio_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats 
*stats);
 static void virtio_dev_stats_reset(struct rte_eth_dev *dev);
 static void virtio_dev_free_mbufs(struct rte_eth_dev *dev);
+static int virtio_vlan_filter_set(struct rte_eth_dev *dev,
+   uint16_t vlan_id, int on);

 static int virtio_dev_queue_stats_mapping_set(
__rte_unused struct rte_eth_dev *eth_dev,
@@ -511,6 +513,7 @@ static struct eth_dev_ops virtio_eth_dev_ops = {
.tx_queue_release= virtio_dev_tx_queue_release,
/* collect stats per queue */
.queue_stats_mapping_set = virtio_dev_queue_stats_mapping_set,
+   .vlan_filter_set = virtio_vlan_filter_set,
 };

 static inline int
@@ -640,14 +643,31 @@ virtio_get_hwaddr(struct virtio_hw *hw)
}
 }

+static int
+virtio_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   struct virtio_pmd_ctrl ctrl;
+   int len;
+
+   if (!vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_VLAN))
+   return -ENOTSUP;
+
+   ctrl.hdr.class = VIRTIO_NET_CTRL_VLAN;
+   ctrl.hdr.cmd = on ? VIRTIO_NET_CTRL_VLAN_ADD : VIRTIO_NET_CTRL_VLAN_DEL;
+   memcpy(ctrl.data, &vlan_id, sizeof(vlan_id));
+   len = sizeof(vlan_id);
+
+   return virtio_send_command(hw->cvq, &ctrl, &len, 1);
+}

 static void
 virtio_negotiate_features(struct virtio_hw *hw)
 {
uint32_t host_features, mask;

-   mask = VIRTIO_NET_F_CTRL_VLAN;
-   mask |= VIRTIO_NET_F_CSUM | VIRTIO_NET_F_GUEST_CSUM;
+   /* checksum offload not implemented */
+   mask = VIRTIO_NET_F_CSUM | VIRTIO_NET_F_GUEST_CSUM;

/* TSO and LRO are only available when their corresponding
 * checksum offload feature is also negotiated.
@@ -1058,6 +1078,13 @@ virtio_dev_configure(struct rte_eth_dev *dev)

hw->vlan_strip = rxmode->hw_vlan_strip;

+   if (rxmode->hw_vlan_filter
+   && !vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_VLAN)) {
+   PMD_DRV_LOG(NOTICE,
+   "vlan filtering not available on this host");
+   return -ENOTSUP;
+   }
+
if (vtpci_irq_config(hw, 0) == VIRTIO_MSI_NO_VECTOR) {
PMD_DRV_LOG(ERR, "failed to set config vector");
return -EBUSY;
-- 
1.8.4.2

[dpdk-dev] [PATCH 12/22] virtio: Move allocation before initialization

[Ouyang Changchun]

If allocation fails, don't want to leave virtio device stuck
in middle of initialization sequence.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index c17cac8..13feda5 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -890,6 +890,15 @@ eth_virtio_dev_init(__rte_unused struct eth_driver 
*eth_drv,
if (rte_eal_process_type() == RTE_PROC_SECONDARY)
return 0;

+   /* Allocate memory for storing MAC addresses */
+   eth_dev->data->mac_addrs = rte_zmalloc("virtio", ETHER_ADDR_LEN, 0);
+   if (eth_dev->data->mac_addrs == NULL) {
+   PMD_INIT_LOG(ERR,
+   "Failed to allocate %d bytes needed to store MAC 
addresses",
+   ETHER_ADDR_LEN);
+   return -ENOMEM;
+   }
+
/* Tell the host we've noticed this device. */
vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_ACK);

@@ -916,15 +925,6 @@ eth_virtio_dev_init(__rte_unused struct eth_driver 
*eth_drv,
hw->vtnet_hdr_size = sizeof(struct virtio_net_hdr);
}

-   /* Allocate memory for storing MAC addresses */
-   eth_dev->data->mac_addrs = rte_zmalloc("virtio", ETHER_ADDR_LEN, 0);
-   if (eth_dev->data->mac_addrs == NULL) {
-   PMD_INIT_LOG(ERR,
-   "Failed to allocate %d bytes needed to store MAC 
addresses",
-   ETHER_ADDR_LEN);
-   return -ENOMEM;
-   }
-
/* Copy the permanent MAC address to: virtio_hw */
virtio_get_hwaddr(hw);
ether_addr_copy((struct ether_addr *) hw->mac_addr,
-- 
1.8.4.2

[dpdk-dev] [PATCH 11/22] virtio: Check for packet headroom at compile time

[Ouyang Changchun]

Better to check at compile time than fail at runtime.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index a07f4ca..c17cac8 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -882,11 +882,7 @@ eth_virtio_dev_init(__rte_unused struct eth_driver 
*eth_drv,
uint32_t offset_conf = sizeof(config->mac);
struct rte_pci_device *pci_dev;

-   if (RTE_PKTMBUF_HEADROOM < sizeof(struct virtio_net_hdr)) {
-   PMD_INIT_LOG(ERR,
-   "MBUF HEADROOM should be enough to hold virtio net 
hdr\n");
-   return -1;
-   }
+   RTE_BUILD_BUG_ON(RTE_PKTMBUF_HEADROOM < sizeof(struct virtio_net_hdr));

eth_dev->dev_ops = &virtio_eth_dev_ops;
eth_dev->tx_pkt_burst = &virtio_xmit_pkts;
-- 
1.8.4.2

[dpdk-dev] [PATCH 10/22] virtio: Make vtpci_get_status local

[Ouyang Changchun]

Make vtpci_get_status a local function as it is used in one file.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_pci.c | 4 +++-
 lib/librte_pmd_virtio/virtio_pci.h | 2 --
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_pci.c 
b/lib/librte_pmd_virtio/virtio_pci.c
index b099e4f..2245bec 100644
--- a/lib/librte_pmd_virtio/virtio_pci.c
+++ b/lib/librte_pmd_virtio/virtio_pci.c
@@ -35,6 +35,8 @@
 #include "virtio_pci.h"
 #include "virtio_logs.h"

+static uint8_t vtpci_get_status(struct virtio_hw *);
+
 void
 vtpci_read_dev_config(struct virtio_hw *hw, uint64_t offset,
void *dst, int length)
@@ -113,7 +115,7 @@ vtpci_reinit_complete(struct virtio_hw *hw)
vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_DRIVER_OK);
 }

-uint8_t
+static uint8_t
 vtpci_get_status(struct virtio_hw *hw)
 {
return VIRTIO_READ_REG_1(hw, VIRTIO_PCI_STATUS);
diff --git a/lib/librte_pmd_virtio/virtio_pci.h 
b/lib/librte_pmd_virtio/virtio_pci.h
index 0a4b578..64d9c34 100644
--- a/lib/librte_pmd_virtio/virtio_pci.h
+++ b/lib/librte_pmd_virtio/virtio_pci.h
@@ -255,8 +255,6 @@ void vtpci_reset(struct virtio_hw *);

 void vtpci_reinit_complete(struct virtio_hw *);

-uint8_t vtpci_get_status(struct virtio_hw *);
-
 void vtpci_set_status(struct virtio_hw *, uint8_t);

 uint32_t vtpci_negotiate_features(struct virtio_hw *, uint32_t);
-- 
1.8.4.2

[dpdk-dev] [PATCH 09/22] virtio: Fix how states are handled during initialization

[Ouyang Changchun]

Change order of initialiazation to match Linux kernel.
Don't blow away control queue by doing reset when stopped.

Calling dev_stop then dev_start would not work.
Dev_stop was calling virtio reset and that would clear all queues
and clear all feature negotiation.
Resolved by only doing reset on device removal.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 58 ---
 lib/librte_pmd_virtio/virtio_pci.c| 10 ++
 lib/librte_pmd_virtio/virtio_pci.h|  3 +-
 3 files changed, 37 insertions(+), 34 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index b7f65b9..a07f4ca 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -398,9 +398,14 @@ virtio_dev_cq_queue_setup(struct rte_eth_dev *dev, 
uint16_t vtpci_queue_idx,
 static void
 virtio_dev_close(struct rte_eth_dev *dev)
 {
+   struct virtio_hw *hw = dev->data->dev_private;
+
PMD_INIT_LOG(DEBUG, "virtio_dev_close");

-   virtio_dev_stop(dev);
+   /* reset the NIC */
+   vtpci_irq_config(hw, VIRTIO_MSI_NO_VECTOR);
+   vtpci_reset(hw);
+   virtio_dev_free_mbufs(dev);
 }

 static void
@@ -889,6 +894,9 @@ eth_virtio_dev_init(__rte_unused struct eth_driver *eth_drv,
if (rte_eal_process_type() == RTE_PROC_SECONDARY)
return 0;

+   /* Tell the host we've noticed this device. */
+   vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_ACK);
+
pci_dev = eth_dev->pci_dev;
if (virtio_resource_init(pci_dev) < 0)
return -1;
@@ -899,9 +907,6 @@ eth_virtio_dev_init(__rte_unused struct eth_driver *eth_drv,
/* Reset the device although not necessary at startup */
vtpci_reset(hw);

-   /* Tell the host we've noticed this device. */
-   vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_ACK);
-
/* Tell the host we've known how to drive the device. */
vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_DRIVER);
virtio_negotiate_features(hw);
@@ -990,6 +995,9 @@ eth_virtio_dev_init(__rte_unused struct eth_driver *eth_drv,
/* Setup interrupt callback  */
rte_intr_callback_register(&pci_dev->intr_handle,
   virtio_interrupt_handler, eth_dev);
+
+   virtio_dev_cq_start(eth_dev);
+
return 0;
 }

@@ -1044,7 +1052,6 @@ virtio_dev_configure(struct rte_eth_dev *dev)
 {
const struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
struct virtio_hw *hw = dev->data->dev_private;
-   int ret;

PMD_INIT_LOG(DEBUG, "configure");

@@ -1055,11 +1062,12 @@ virtio_dev_configure(struct rte_eth_dev *dev)

hw->vlan_strip = rxmode->hw_vlan_strip;

-   ret = vtpci_irq_config(hw, 0);
-   if (ret != 0)
+   if (vtpci_irq_config(hw, 0) == VIRTIO_MSI_NO_VECTOR) {
PMD_DRV_LOG(ERR, "failed to set config vector");
+   return -EBUSY;
+   }

-   return ret;
+   return 0;
 }


@@ -1069,17 +1077,6 @@ virtio_dev_start(struct rte_eth_dev *dev)
uint16_t nb_queues, i;
struct virtio_hw *hw = dev->data->dev_private;

-   /* Tell the host we've noticed this device. */
-   vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_ACK);
-
-   /* Tell the host we've known how to drive the device. */
-   vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_DRIVER);
-
-   virtio_dev_cq_start(dev);
-
-   /* Do final configuration before rx/tx engine starts */
-   virtio_dev_rxtx_start(dev);
-
/* check if lsc interrupt feature is enabled */
if (dev->data->dev_conf.intr_conf.lsc) {
if (!vtpci_with_feature(hw, VIRTIO_NET_F_STATUS)) {
@@ -1096,8 +1093,16 @@ virtio_dev_start(struct rte_eth_dev *dev)
/* Initialize Link state */
virtio_dev_link_update(dev, 0);

+   /* On restart after stop do not touch queues */
+   if (hw->started)
+   return 0;
+
vtpci_reinit_complete(hw);

+   /* Do final configuration before rx/tx engine starts */
+   virtio_dev_rxtx_start(dev);
+   hw->started = 1;
+
/*Notify the backend
 *Otherwise the tap backend might already stop its queue due to 
fullness.
 *vhost backend will have no chance to be waked up
@@ -1168,17 +1173,20 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev 
*dev)
 }

 /*
- * Stop device: disable rx and tx functions to allow for reconfiguring.
+ * Stop device: disable interrupt and mark link down
  */
 static void
 virtio_dev_stop(struct rte_eth_dev *dev)
 {
-   struct virtio_hw *hw = dev->data->dev_private;
+   struct rte_eth_link link;

-   /* reset the NIC */
-   vtpci_irq_config(hw, 0);
-   vtpci_reset(hw);
-   virtio_dev_free_mbufs(dev);
+   PMD_INIT_LOG(DEBUG, "stop");
+
+   if (dev->data->dev_conf.intr_conf.lsc)
+   rte_intr_disable(&dev->pci_dev-

[dpdk-dev] [PATCH 08/22] virtio: Remove redundant vq_alignment

[Ouyang Changchun]

Since vq_alignment is constant (always 4K), it does not
need to be part of the vring struct.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 1 -
 lib/librte_pmd_virtio/virtio_rxtx.c   | 2 +-
 lib/librte_pmd_virtio/virtqueue.h | 3 +--
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index c89614d..b7f65b9 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -294,7 +294,6 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
vq->port_id = dev->data->port_id;
vq->queue_id = queue_idx;
vq->vq_queue_index = vtpci_queue_idx;
-   vq->vq_alignment = VIRTIO_PCI_VRING_ALIGN;
vq->vq_nentries = vq_size;
vq->vq_free_cnt = vq_size;

diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
b/lib/librte_pmd_virtio/virtio_rxtx.c
index 73ad3ac..b44f091 100644
--- a/lib/librte_pmd_virtio/virtio_rxtx.c
+++ b/lib/librte_pmd_virtio/virtio_rxtx.c
@@ -258,7 +258,7 @@ virtio_dev_vring_start(struct virtqueue *vq, int queue_type)
 * Reinitialise since virtio port might have been stopped and restarted
 */
memset(vq->vq_ring_virt_mem, 0, vq->vq_ring_size);
-   vring_init(vr, size, ring_mem, vq->vq_alignment);
+   vring_init(vr, size, ring_mem, VIRTIO_PCI_VRING_ALIGN);
vq->vq_used_cons_idx = 0;
vq->vq_desc_head_idx = 0;
vq->vq_avail_idx = 0;
diff --git a/lib/librte_pmd_virtio/virtqueue.h 
b/lib/librte_pmd_virtio/virtqueue.h
index f6ad98d..5b8a255 100644
--- a/lib/librte_pmd_virtio/virtqueue.h
+++ b/lib/librte_pmd_virtio/virtqueue.h
@@ -138,8 +138,7 @@ struct virtqueue {
uint8_t port_id;  /**< Device port identifier. */

void*vq_ring_virt_mem;/**< linear address of vring*/
-   int vq_alignment;
-   int vq_ring_size;
+   unsigned int vq_ring_size;
phys_addr_t vq_ring_mem;  /**< physical address of vring */

struct vring vq_ring;/**< vring keeping desc, used and avail */
-- 
1.8.4.2

[dpdk-dev] [PATCH 07/22] virtio: Remove unnecessary adapter structure

[Ouyang Changchun]

Cleanup virtio code by eliminating unnecessary nesting of
virtio hardware structure inside adapter structure.
Also allows removing unneeded macro, making code clearer.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 43 ---
 lib/librte_pmd_virtio/virtio_ethdev.h |  9 
 lib/librte_pmd_virtio/virtio_rxtx.c   |  3 +--
 3 files changed, 16 insertions(+), 39 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index 829838c..c89614d 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -207,8 +207,7 @@ virtio_send_command(struct virtqueue *vq, struct 
virtio_pmd_ctrl *ctrl,
 static int
 virtio_set_multiple_queues(struct rte_eth_dev *dev, uint16_t nb_queues)
 {
-   struct virtio_hw *hw
-   = VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct virtio_hw *hw = dev->data->dev_private;
struct virtio_pmd_ctrl ctrl;
int dlen[1];
int ret;
@@ -242,8 +241,7 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
const struct rte_memzone *mz;
uint16_t vq_size;
int size;
-   struct virtio_hw *hw =
-   VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct virtio_hw *hw = dev->data->dev_private;
struct virtqueue  *vq = NULL;

/* Write the virtqueue index to the Queue Select Field */
@@ -383,8 +381,7 @@ virtio_dev_cq_queue_setup(struct rte_eth_dev *dev, uint16_t 
vtpci_queue_idx,
struct virtqueue *vq;
uint16_t nb_desc = 0;
int ret;
-   struct virtio_hw *hw =
-   VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct virtio_hw *hw = dev->data->dev_private;

PMD_INIT_FUNC_TRACE();
ret = virtio_dev_queue_setup(dev, VTNET_CQ, VTNET_SQ_CQ_QUEUE_IDX,
@@ -410,8 +407,7 @@ virtio_dev_close(struct rte_eth_dev *dev)
 static void
 virtio_dev_promiscuous_enable(struct rte_eth_dev *dev)
 {
-   struct virtio_hw *hw
-   = VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct virtio_hw *hw = dev->data->dev_private;
struct virtio_pmd_ctrl ctrl;
int dlen[1];
int ret;
@@ -430,8 +426,7 @@ virtio_dev_promiscuous_enable(struct rte_eth_dev *dev)
 static void
 virtio_dev_promiscuous_disable(struct rte_eth_dev *dev)
 {
-   struct virtio_hw *hw
-   = VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct virtio_hw *hw = dev->data->dev_private;
struct virtio_pmd_ctrl ctrl;
int dlen[1];
int ret;
@@ -450,8 +445,7 @@ virtio_dev_promiscuous_disable(struct rte_eth_dev *dev)
 static void
 virtio_dev_allmulticast_enable(struct rte_eth_dev *dev)
 {
-   struct virtio_hw *hw
-   = VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct virtio_hw *hw = dev->data->dev_private;
struct virtio_pmd_ctrl ctrl;
int dlen[1];
int ret;
@@ -470,8 +464,7 @@ virtio_dev_allmulticast_enable(struct rte_eth_dev *dev)
 static void
 virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
 {
-   struct virtio_hw *hw
-   = VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct virtio_hw *hw = dev->data->dev_private;
struct virtio_pmd_ctrl ctrl;
int dlen[1];
int ret;
@@ -853,8 +846,7 @@ virtio_interrupt_handler(__rte_unused struct 
rte_intr_handle *handle,
 void *param)
 {
struct rte_eth_dev *dev = param;
-   struct virtio_hw *hw =
-   VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct virtio_hw *hw = dev->data->dev_private;
uint8_t isr;

/* Read interrupt status which clears interrupt */
@@ -880,12 +872,11 @@ static int
 eth_virtio_dev_init(__rte_unused struct eth_driver *eth_drv,
struct rte_eth_dev *eth_dev)
 {
+   struct virtio_hw *hw = eth_dev->data->dev_private;
struct virtio_net_config *config;
struct virtio_net_config local_config;
uint32_t offset_conf = sizeof(config->mac);
struct rte_pci_device *pci_dev;
-   struct virtio_hw *hw =
-   VIRTIO_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);

if (RTE_PKTMBUF_HEADROOM < sizeof(struct virtio_net_hdr)) {
PMD_INIT_LOG(ERR,
@@ -1010,7 +1001,7 @@ static struct eth_driver rte_virtio_pmd = {
.drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
},
.eth_dev_init = eth_virtio_dev_init,
-   .dev_private_size = sizeof(struct virtio_adapter),
+   .dev_private_size = sizeof(struct virtio_hw),
 };

 /*
@@ -1053,8 +1044,7 @@ static int
 virtio_dev_configure(struct rte_eth_dev *dev)
 {
const struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
-   struct virtio_hw *hw =
-   VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+  

[dpdk-dev] [PATCH 06/22] virtio: Use software vlan stripping

[Ouyang Changchun]

Implement VLAN stripping in software. This allows application
to be device independent.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_ether/rte_ethdev.h |  3 +++
 lib/librte_pmd_virtio/virtio_ethdev.c |  2 ++
 lib/librte_pmd_virtio/virtio_pci.h|  1 +
 lib/librte_pmd_virtio/virtio_rxtx.c   | 20 ++--
 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index f66805d..07d55b8 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -643,6 +643,9 @@ struct rte_eth_rxconf {
 #define ETH_TXQ_FLAGS_NOOFFLOADS \
(ETH_TXQ_FLAGS_NOVLANOFFL | ETH_TXQ_FLAGS_NOXSUMSCTP | \
 ETH_TXQ_FLAGS_NOXSUMUDP  | ETH_TXQ_FLAGS_NOXSUMTCP)
+#define ETH_TXQ_FLAGS_NOXSUMS \
+   (ETH_TXQ_FLAGS_NOXSUMSCTP | ETH_TXQ_FLAGS_NOXSUMUDP | \
+ETH_TXQ_FLAGS_NOXSUMTCP)
 /**
  * A structure used to configure a TX ring of an Ethernet port.
  */
diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index d37f2e9..829838c 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -1064,6 +1064,8 @@ virtio_dev_configure(struct rte_eth_dev *dev)
return (-EINVAL);
}

+   hw->vlan_strip = rxmode->hw_vlan_strip;
+
ret = vtpci_irq_config(hw, 0);
if (ret != 0)
PMD_DRV_LOG(ERR, "failed to set config vector");
diff --git a/lib/librte_pmd_virtio/virtio_pci.h 
b/lib/librte_pmd_virtio/virtio_pci.h
index 6998737..6d93fac 100644
--- a/lib/librte_pmd_virtio/virtio_pci.h
+++ b/lib/librte_pmd_virtio/virtio_pci.h
@@ -168,6 +168,7 @@ struct virtio_hw {
uint32_tmax_tx_queues;
uint32_tmax_rx_queues;
uint16_tvtnet_hdr_size;
+   uint8_t vlan_strip;
uint8_t use_msix;
uint8_t mac_addr[ETHER_ADDR_LEN];
 };
diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
b/lib/librte_pmd_virtio/virtio_rxtx.c
index f878c62..a5756e1 100644
--- a/lib/librte_pmd_virtio/virtio_rxtx.c
+++ b/lib/librte_pmd_virtio/virtio_rxtx.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "virtio_logs.h"
 #include "virtio_ethdev.h"
@@ -408,8 +409,8 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,

PMD_INIT_FUNC_TRACE();

-   if ((tx_conf->txq_flags & ETH_TXQ_FLAGS_NOOFFLOADS)
-   != ETH_TXQ_FLAGS_NOOFFLOADS) {
+   if ((tx_conf->txq_flags & ETH_TXQ_FLAGS_NOXSUMS)
+   != ETH_TXQ_FLAGS_NOXSUMS) {
PMD_INIT_LOG(ERR, "TX checksum offload not supported\n");
return -EINVAL;
}
@@ -446,6 +447,7 @@ uint16_t
 virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
 {
struct virtqueue *rxvq = rx_queue;
+   struct virtio_hw *hw = rxvq->hw;
struct rte_mbuf *rxm, *new_mbuf;
uint16_t nb_used, num, nb_rx = 0;
uint32_t len[VIRTIO_MBUF_BURST_SZ];
@@ -489,6 +491,9 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
rxm->pkt_len = (uint32_t)(len[i] - hdr_size);
rxm->data_len = (uint16_t)(len[i] - hdr_size);

+   if (hw->vlan_strip)
+   rte_vlan_strip(rxm);
+
VIRTIO_DUMP_PACKET(rxm, rxm->data_len);

rx_pkts[nb_rx++] = rxm;
@@ -717,6 +722,17 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts, uint16_t nb_pkts)
 */
if (likely(need <= 0)) {
txm = tx_pkts[nb_tx];
+
+   /* Do VLAN tag insertion */
+   if (txm->ol_flags & PKT_TX_VLAN_PKT) {
+   error = rte_vlan_insert(&txm);
+   if (unlikely(error)) {
+   rte_pktmbuf_free(txm);
+   ++nb_tx;
+   continue;
+   }
+   }
+
/* Enqueue Packet buffers */
error = virtqueue_enqueue_xmit(txvq, txm);
if (unlikely(error)) {
-- 
1.8.4.2

[dpdk-dev] [PATCH 05/22] ether: Add soft vlan encap/decap functions

[Ouyang Changchun]

It is helpful to allow device drivers that don't support hardware
VLAN stripping to emulate this in software. This allows application
to be device independent.

Avoid discarding shared mbufs. Make a copy in rte_vlan_insert() of any
packet to be tagged that has a reference count > 1.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_ether/rte_ether.h | 76 
 1 file changed, 76 insertions(+)

diff --git a/lib/librte_ether/rte_ether.h b/lib/librte_ether/rte_ether.h
index 187608d..3b6ab4b 100644
--- a/lib/librte_ether/rte_ether.h
+++ b/lib/librte_ether/rte_ether.h
@@ -49,6 +49,8 @@ extern "C" {

 #include 
 #include 
+#include 
+#include 

 #define ETHER_ADDR_LEN  6 /**< Length of Ethernet address. */
 #define ETHER_TYPE_LEN  2 /**< Length of Ethernet type field. */
@@ -332,6 +334,80 @@ struct vxlan_hdr {
 #define ETHER_VXLAN_HLEN (sizeof(struct udp_hdr) + sizeof(struct vxlan_hdr))
 /**< VXLAN tunnel header length. */

+/**
+ * Extract VLAN tag information into mbuf
+ *
+ * Software version of VLAN stripping
+ *
+ * @param m
+ *   The packet mbuf.
+ * @return
+ *   - 0: Success
+ *   - 1: not a vlan packet
+ */
+static inline int rte_vlan_strip(struct rte_mbuf *m)
+{
+   struct ether_hdr *eh
+= rte_pktmbuf_mtod(m, struct ether_hdr *);
+
+   if (eh->ether_type != ETHER_TYPE_VLAN)
+   return -1;
+
+   struct vlan_hdr *vh = (struct vlan_hdr *)(eh + 1);
+   m->ol_flags |= PKT_RX_VLAN_PKT;
+   m->vlan_tci = rte_be_to_cpu_16(vh->vlan_tci);
+
+   /* Copy ether header over rather than moving whole packet */
+   memmove(rte_pktmbuf_adj(m, sizeof(struct vlan_hdr)),
+   eh, 2 * ETHER_ADDR_LEN);
+
+   return 0;
+}
+
+/**
+ * Insert VLAN tag into mbuf.
+ *
+ * Software version of VLAN unstripping
+ *
+ * @param m
+ *   The packet mbuf.
+ * @return
+ *   - 0: On success
+ *   -EPERM: mbuf is is shared overwriting would be unsafe
+ *   -ENOSPC: not enough headroom in mbuf
+ */
+static inline int rte_vlan_insert(struct rte_mbuf **m)
+{
+   struct ether_hdr *oh, *nh;
+   struct vlan_hdr *vh;
+
+#ifdef RTE_MBUF_REFCNT
+   /* Can't insert header if mbuf is shared */
+   if (rte_mbuf_refcnt_read(*m) > 1) {
+   struct rte_mbuf *copy;
+
+   copy = rte_pktmbuf_clone(*m, (*m)->pool);
+   if (unlikely(copy == NULL))
+   return -ENOMEM;
+   rte_pktmbuf_free(*m);
+   *m = copy;
+   }
+#endif
+   oh = rte_pktmbuf_mtod(*m, struct ether_hdr *);
+   nh = (struct ether_hdr *)
+   rte_pktmbuf_prepend(*m, sizeof(struct vlan_hdr));
+   if (nh == NULL)
+   return -ENOSPC;
+
+   memmove(nh, oh, 2 * ETHER_ADDR_LEN);
+   nh->ether_type = ETHER_TYPE_VLAN;
+
+   vh = (struct vlan_hdr *) (nh + 1);
+   vh->vlan_tci = rte_cpu_to_be_16((*m)->vlan_tci);
+
+   return 0;
+}
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.8.4.2

[dpdk-dev] [PATCH 04/22] virtio: Add support for Link State interrupt

[Ouyang Changchun]

Virtio has link state interrupt which can be used.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 78 +++
 lib/librte_pmd_virtio/virtio_pci.c| 22 ++
 lib/librte_pmd_virtio/virtio_pci.h|  4 ++
 3 files changed, 86 insertions(+), 18 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index 4bff0fe..d37f2e9 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -845,6 +845,34 @@ static int virtio_resource_init(struct rte_pci_device 
*pci_dev __rte_unused)
 #endif

 /*
+ * Process Virtio Config changed interrupt and call the callback
+ * if link state changed.
+ */
+static void
+virtio_interrupt_handler(__rte_unused struct rte_intr_handle *handle,
+void *param)
+{
+   struct rte_eth_dev *dev = param;
+   struct virtio_hw *hw =
+   VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   uint8_t isr;
+
+   /* Read interrupt status which clears interrupt */
+   isr = vtpci_isr(hw);
+   PMD_DRV_LOG(INFO, "interrupt status = %#x", isr);
+
+   if (rte_intr_enable(&dev->pci_dev->intr_handle) < 0)
+   PMD_DRV_LOG(ERR, "interrupt enable failed");
+
+   if (isr & VIRTIO_PCI_ISR_CONFIG) {
+   if (virtio_dev_link_update(dev, 0) == 0)
+   _rte_eth_dev_callback_process(dev,
+ RTE_ETH_EVENT_INTR_LSC);
+   }
+
+}
+
+/*
  * This function is based on probe() function in virtio_pci.c
  * It returns 0 on success.
  */
@@ -968,6 +996,10 @@ eth_virtio_dev_init(__rte_unused struct eth_driver 
*eth_drv,
PMD_INIT_LOG(DEBUG, "port %d vendorID=0x%x deviceID=0x%x",
eth_dev->data->port_id, pci_dev->id.vendor_id,
pci_dev->id.device_id);
+
+   /* Setup interrupt callback  */
+   rte_intr_callback_register(&pci_dev->intr_handle,
+  virtio_interrupt_handler, eth_dev);
return 0;
 }

@@ -975,7 +1007,7 @@ static struct eth_driver rte_virtio_pmd = {
{
.name = "rte_virtio_pmd",
.id_table = pci_id_virtio_map,
-   .drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+   .drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
},
.eth_dev_init = eth_virtio_dev_init,
.dev_private_size = sizeof(struct virtio_adapter),
@@ -1021,6 +1053,9 @@ static int
 virtio_dev_configure(struct rte_eth_dev *dev)
 {
const struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
+   struct virtio_hw *hw =
+   VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   int ret;

PMD_INIT_LOG(DEBUG, "configure");

@@ -1029,7 +1064,11 @@ virtio_dev_configure(struct rte_eth_dev *dev)
return (-EINVAL);
}

-   return 0;
+   ret = vtpci_irq_config(hw, 0);
+   if (ret != 0)
+   PMD_DRV_LOG(ERR, "failed to set config vector");
+
+   return ret;
 }


@@ -1037,7 +1076,6 @@ static int
 virtio_dev_start(struct rte_eth_dev *dev)
 {
uint16_t nb_queues, i;
-   uint16_t status;
struct virtio_hw *hw =
VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);

@@ -1052,18 +1090,22 @@ virtio_dev_start(struct rte_eth_dev *dev)
/* Do final configuration before rx/tx engine starts */
virtio_dev_rxtx_start(dev);

-   /* Check VIRTIO_NET_F_STATUS for link status*/
-   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS)) {
-   vtpci_read_dev_config(hw,
-   offsetof(struct virtio_net_config, status),
-   &status, sizeof(status));
-   if ((status & VIRTIO_NET_S_LINK_UP) == 0)
-   PMD_INIT_LOG(ERR, "Port: %d Link is DOWN",
-dev->data->port_id);
-   else
-   PMD_INIT_LOG(DEBUG, "Port: %d Link is UP",
-dev->data->port_id);
+   /* check if lsc interrupt feature is enabled */
+   if (dev->data->dev_conf.intr_conf.lsc) {
+   if (!vtpci_with_feature(hw, VIRTIO_NET_F_STATUS)) {
+   PMD_DRV_LOG(ERR, "link status not supported by host");
+   return -ENOTSUP;
+   }
+
+   if (rte_intr_enable(&dev->pci_dev->intr_handle) < 0) {
+   PMD_DRV_LOG(ERR, "interrupt enable failed");
+   return -EIO;
+   }
}
+
+   /* Initialize Link state */
+   virtio_dev_link_update(dev, 0);
+
vtpci_reinit_complete(hw);

/*Notify the backend
@@ -1145,6 +1187,7 @@ virtio_dev_stop(struct rte_eth_dev *dev)
VIRTIO_DEV_PRIVATE_TO_HW(dev->data->dev_private);

/* reset the

[dpdk-dev] [PATCH 03/22] virtio: Allow starting with link down

[Ouyang Changchun]

Starting driver with link down should be ok, it is with every
other driver. So just allow it.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index 78018f9..4bff0fe 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -1057,14 +1057,12 @@ virtio_dev_start(struct rte_eth_dev *dev)
vtpci_read_dev_config(hw,
offsetof(struct virtio_net_config, status),
&status, sizeof(status));
-   if ((status & VIRTIO_NET_S_LINK_UP) == 0) {
+   if ((status & VIRTIO_NET_S_LINK_UP) == 0)
PMD_INIT_LOG(ERR, "Port: %d Link is DOWN",
 dev->data->port_id);
-   return -EIO;
-   } else {
+   else
PMD_INIT_LOG(DEBUG, "Port: %d Link is UP",
 dev->data->port_id);
-   }
}
vtpci_reinit_complete(hw);

-- 
1.8.4.2

[dpdk-dev] [PATCH 02/22] virtio: Use weaker barriers

[Ouyang Changchun]

The DPDK driver only has to deal with the case of running on PCI
and with SMP. In this case, the code can use the weaker barriers
instead of using hard (fence) barriers. This will help performance.
The rationale is explained in Linux kernel virtio_ring.h.

To make it clearer that this is a virtio thing and not some generic
barrier, prefix the barrier calls with virtio_.

Add missing (and needed) barrier between updating ring data
structure and notifying host.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c |  2 +-
 lib/librte_pmd_virtio/virtio_rxtx.c   |  8 +---
 lib/librte_pmd_virtio/virtqueue.h | 19 ++-
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index 6c31598..78018f9 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -175,7 +175,7 @@ virtio_send_command(struct virtqueue *vq, struct 
virtio_pmd_ctrl *ctrl,
uint32_t idx, desc_idx, used_idx;
struct vring_used_elem *uep;

-   rmb();
+   virtio_rmb();

used_idx = (uint32_t)(vq->vq_used_cons_idx
& (vq->vq_nentries - 1));
diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
b/lib/librte_pmd_virtio/virtio_rxtx.c
index 3f6bad2..f878c62 100644
--- a/lib/librte_pmd_virtio/virtio_rxtx.c
+++ b/lib/librte_pmd_virtio/virtio_rxtx.c
@@ -456,7 +456,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)

nb_used = VIRTQUEUE_NUSED(rxvq);

-   rmb();
+   virtio_rmb();

num = (uint16_t)(likely(nb_used <= nb_pkts) ? nb_used : nb_pkts);
num = (uint16_t)(likely(num <= VIRTIO_MBUF_BURST_SZ) ? num : 
VIRTIO_MBUF_BURST_SZ);
@@ -516,6 +516,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
}

if (likely(nb_enqueued)) {
+   virtio_wmb();
if (unlikely(virtqueue_kick_prepare(rxvq))) {
virtqueue_notify(rxvq);
PMD_RX_LOG(DEBUG, "Notified\n");
@@ -547,7 +548,7 @@ virtio_recv_mergeable_pkts(void *rx_queue,

nb_used = VIRTQUEUE_NUSED(rxvq);

-   rmb();
+   virtio_rmb();

if (nb_used == 0)
return 0;
@@ -694,7 +695,7 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)
PMD_TX_LOG(DEBUG, "%d packets to xmit", nb_pkts);
nb_used = VIRTQUEUE_NUSED(txvq);

-   rmb();
+   virtio_rmb();

num = (uint16_t)(likely(nb_used < VIRTIO_MBUF_BURST_SZ) ? nb_used : 
VIRTIO_MBUF_BURST_SZ);

@@ -735,6 +736,7 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, 
uint16_t nb_pkts)
}
}
vq_update_avail_idx(txvq);
+   virtio_wmb();

txvq->packets += nb_tx;

diff --git a/lib/librte_pmd_virtio/virtqueue.h 
b/lib/librte_pmd_virtio/virtqueue.h
index fdee054..f6ad98d 100644
--- a/lib/librte_pmd_virtio/virtqueue.h
+++ b/lib/librte_pmd_virtio/virtqueue.h
@@ -46,9 +46,18 @@
 #include "virtio_ring.h"
 #include "virtio_logs.h"

-#define mb()  rte_mb()
-#define wmb() rte_wmb()
-#define rmb() rte_rmb()
+/*
+ * Per virtio_config.h in Linux.
+ * For virtio_pci on SMP, we don't need to order with respect to MMIO
+ * accesses through relaxed memory I/O windows, so smp_mb() et al are
+ * sufficient.
+ *
+ * This driver is for virtio_pci on SMP and therefore can assume
+ * weaker (compiler barriers)
+ */
+#define virtio_mb()rte_mb()
+#define virtio_rmb()   rte_compiler_barrier()
+#define virtio_wmb()   rte_compiler_barrier()

 #ifdef RTE_PMD_PACKET_PREFETCH
 #define rte_packet_prefetch(p)  rte_prefetch1(p)
@@ -225,7 +234,7 @@ virtqueue_full(const struct virtqueue *vq)
 static inline void
 vq_update_avail_idx(struct virtqueue *vq)
 {
-   rte_compiler_barrier();
+   virtio_rmb();
vq->vq_ring.avail->idx = vq->vq_avail_idx;
 }

@@ -255,7 +264,7 @@ static inline void
 virtqueue_notify(struct virtqueue *vq)
 {
/*
-* Ensure updated avail->idx is visible to host. mb() necessary?
+* Ensure updated avail->idx is visible to host.
 * For virtio on IA, the notificaiton is through io port operation
 * which is a serialization instruction itself.
 */
-- 
1.8.4.2

[dpdk-dev] [PATCH 01/22] virtio: Rearrange resource initialization

[Ouyang Changchun]

For clarity make the setup of PCI resources for Linux into a function rather
than block of code #ifdef'd in middle of dev_init.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Changchun Ouyang 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 76 ---
 1 file changed, 43 insertions(+), 33 deletions(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index c009f2a..6c31598 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -794,6 +794,41 @@ virtio_has_msix(const struct rte_pci_addr *loc)

return (d != NULL);
 }
+
+/* Extract I/O port numbers from sysfs */
+static int virtio_resource_init(struct rte_pci_device *pci_dev)
+{
+   char dirname[PATH_MAX];
+   char filename[PATH_MAX];
+   unsigned long start, size;
+
+   if (get_uio_dev(&pci_dev->addr, dirname, sizeof(dirname)) < 0)
+   return -1;
+
+   /* get portio size */
+   snprintf(filename, sizeof(filename),
+"%s/portio/port0/size", dirname);
+   if (parse_sysfs_value(filename, &size) < 0) {
+   PMD_INIT_LOG(ERR, "%s(): cannot parse size",
+__func__);
+   return -1;
+   }
+
+   /* get portio start */
+   snprintf(filename, sizeof(filename),
+"%s/portio/port0/start", dirname);
+   if (parse_sysfs_value(filename, &start) < 0) {
+   PMD_INIT_LOG(ERR, "%s(): cannot parse portio start",
+__func__);
+   return -1;
+   }
+   pci_dev->mem_resource[0].addr = (void *)(uintptr_t)start;
+   pci_dev->mem_resource[0].len =  (uint64_t)size;
+   PMD_INIT_LOG(DEBUG,
+"PCI Port IO found start=0x%lx with size=0x%lx",
+start, size);
+   return 0;
+}
 #else
 static int
 virtio_has_msix(const struct rte_pci_addr *loc __rte_unused)
@@ -801,6 +836,12 @@ virtio_has_msix(const struct rte_pci_addr *loc 
__rte_unused)
/* nic_uio does not enable interrupts, return 0 (false). */
return 0;
 }
+
+static int virtio_resource_init(struct rte_pci_device *pci_dev __rte_unused)
+{
+   /* no setup required */
+   return 0;
+}
 #endif

 /*
@@ -831,40 +872,9 @@ eth_virtio_dev_init(__rte_unused struct eth_driver 
*eth_drv,
return 0;

pci_dev = eth_dev->pci_dev;
+   if (virtio_resource_init(pci_dev) < 0)
+   return -1;

-#ifdef RTE_EXEC_ENV_LINUXAPP
-   {
-   char dirname[PATH_MAX];
-   char filename[PATH_MAX];
-   unsigned long start, size;
-
-   if (get_uio_dev(&pci_dev->addr, dirname, sizeof(dirname)) < 0)
-   return -1;
-
-   /* get portio size */
-   snprintf(filename, sizeof(filename),
-"%s/portio/port0/size", dirname);
-   if (parse_sysfs_value(filename, &size) < 0) {
-   PMD_INIT_LOG(ERR, "%s(): cannot parse size",
-__func__);
-   return -1;
-   }
-
-   /* get portio start */
-   snprintf(filename, sizeof(filename),
-"%s/portio/port0/start", dirname);
-   if (parse_sysfs_value(filename, &start) < 0) {
-   PMD_INIT_LOG(ERR, "%s(): cannot parse portio start",
-__func__);
-   return -1;
-   }
-   pci_dev->mem_resource[0].addr = (void *)(uintptr_t)start;
-   pci_dev->mem_resource[0].len =  (uint64_t)size;
-   PMD_INIT_LOG(DEBUG,
-"PCI Port IO found start=0x%lx with size=0x%lx",
-start, size);
-   }
-#endif
hw->use_msix = virtio_has_msix(&pci_dev->addr);
hw->io_base = (uint32_t)(uintptr_t)pci_dev->mem_resource[0].addr;

-- 
1.8.4.2

[dpdk-dev] [PATCH 00/22] Single virtio implementation

[Ouyang Changchun]

This is the patch set for single virtio implementation.

Why we need single virtio?

As we know currently there are at least 3 virtio PMD driver implementations:
A) lib/librte_pmd_virtio(refer as virtio A);
B) virtio_net_pmd by 6wind(refer as virtio B);
C) virtio by Brocade/vyatta(refer as virtio C);

Integrating 3 implementations into one could reduce the maintaining cost and 
time,
in other hand, user don't need practice their application on 3 variant one by 
one to see
which one is the best for them;

What's the status?

Currently virtio A has covered most features of virtio B except for using port 
io to get pci resource, 
so there is a patch(17/22) to resolve it. But on the other hand there are a few 
differences between
virtio A and virtio C, it needs integrate features/codes of virtio C into 
virtio A.
This patch set bases on two original RFC patch sets from Stephen 
Hemminger[stephen at networkplumber.org]
Refer to [http://dpdk.org/ml/archives/dev/2014-August/004845.html ] for the 
original one.
This patch set also resolves some conflict with latest codes, removed 
duplicated codes, fix some 
issues in original codes.

What this patch set contains:
===
  1) virtio: Rearrange resource initialization, it extracts a function to setup 
PCI resources;
  2) virtio: Use weaker barriers, as DPDK driver only has to deal with the case 
of running on PCI
 and with SMP, In this case, the code can use the weaker barriers instead 
of using hard (fence)
 barriers. This may help performance a bit;
  3) virtio: Allow starting with link down, other driver has similar behavior;
  4) virtio: Add support for Link State interrupt;
  5) ether: Add soft vlan encap/decap functions, it helps if HW don't support 
vlan strip;
  6) virtio: Use software vlan stripping;
  7) virtio: Remove unnecessary adapter structure;
  8) virtio: Remove redundant vq_alignment, as vq alignment is always 4K, so 
use constant when needed;
  9) virtio: Fix how states are handled during initialization, this is to match 
Linux kernel;
  10) virtio: Make vtpci_get_status a local function as it is used in one file;
  11) virtio: Check for packet headroom at compile time;
  12) virtio: Move allocation before initialization to avoid being stuck in 
middle of virtio init;
  13) virtio: Add support for vlan filtering;
  14) virtio: Add support for multiple mac addresses;
  15) virtio: Add ability to set MAC address;
  16) virtio: Free mbuf's with threshold, this makes its behavior more like 
ixgbe;
  17) virtio: Use port IO to get PCI resource for security reasons and match 
virtio-net-pmd;
  18) virtio: Fix descriptor index issue;
  19) ether: Fix vlan strip/insert issue;
  20) example/vhost: Avoid inserting vlan twice and guest and host;
  21) example/vhost: Add vlan-strip cmd line option to turn on/off vlan strip 
on host;
  22) virtio: Use soft vlan strip in mergeable Rx path, this makes it has 
consistent logic
  with the normal Rx path.

Changchun Ouyang (6):
  virtio: Use port IO to get PCI resource.
  virtio: Fix descriptor index issue
  ether: Fix vlan strip/insert issue
  example/vhost: Avoid inserting vlan twice
  example/vhost: Add vlan-strip cmd line option
  virtio: Use soft vlan strip in mergeable Rx path

Stephen Hemminger (16):
  virtio: Rearrange resource initialization
  virtio: Use weaker barriers
  virtio: Allow starting with link down
  virtio: Add support for Link State interrupt
  ether: Add soft vlan encap/decap functions
  virtio: Use software vlan stripping
  virtio: Remove unnecessary adapter structure
  virtio: Remove redundant vq_alignment
  virtio: Fix how states are handled during initialization
  virtio: Make vtpci_get_status local
  virtio: Check for packet headroom at compile time
  virtio: Move allocation before initialization
  virtio: Add support for vlan filtering
  virtio: Add suport for multiple mac addresses
  virtio: Add ability to set MAC address
  virtio: Free mbuf's with threshold

 config/common_linuxapp  |   2 +
 examples/vhost/main.c   |  43 ++-
 lib/librte_eal/common/include/rte_pci.h |   4 +
 lib/librte_eal/linuxapp/eal/eal_pci.c   |   5 +-
 lib/librte_ether/rte_ethdev.h   |   8 +
 lib/librte_ether/rte_ether.h|  76 +
 lib/librte_pmd_virtio/virtio_ethdev.c   | 497 +---
 lib/librte_pmd_virtio/virtio_ethdev.h   |  12 +-
 lib/librte_pmd_virtio/virtio_pci.c  |  20 +-
 lib/librte_pmd_virtio/virtio_pci.h  |   8 +-
 lib/librte_pmd_virtio/virtio_rxtx.c | 110 +--
 lib/librte_pmd_virtio/virtqueue.h   |  59 +++-
 12 files changed, 676 insertions(+), 168 deletions(-)

-- 
1.8.4.2

[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[Ravi Kerur]

On Wed, Jan 14, 2015 at 8:27 AM, Thomas Monjalon 
wrote:

> 2015-01-09 04:41, Ravi Kerur:
> > Thomas,
> >
> > Please let me know how I can move forward on this. If i confine changes
> in
> > e1000/ directory to e1000_osdep.h file only and the rest in PMD will that
> > work? The reason I ask is because of following comment  in README file.
> >
> > ...
> > Few changes to the original FreeBSD sources were made to:
> > - Adopt it for PMD usage mode:
> > e1000_osdep.c
> > e1000_osdep.h
> > ...
>
> This is an Intel driver so you should ask to the responsible of this code
> at Intel.
> The problem is that there is not really an identified responsible for this
> driver.
>
> The rule is to not change the base driver, even osdep files.
> But it would be better to have an exception here.
>
>
> PS: please avoid top-posting.
>

 Please let me know who is the contact person from Intel so I can add
him/her to "To" list when I send the patch or Should I contact Jim St Leger
and ask him about this?

Thanks.

>
> > On Mon, Jan 5, 2015 at 8:40 AM, Ravi Kerur  wrote:
> >
> > > Inline 
> > >
> > > On Mon, Jan 5, 2015 at 12:55 AM, Thomas Monjalon <
> > > thomas.monjalon at 6wind.com> wrote:
> > >
> > >> 2015-01-04 15:28, Ravi Kerur:
> > >> > We have a Gigabyte H97N motherboard which has I217 Intel chipset
> which
> > >> uses
> > >> > e100e drivers. I looked into lib/librte_pmd_e1000 directory and I
> do see
> > >> > that e1000e code is integrated but missing some support for
> read/write
> > >> from
> > >> > flash_address and other minor things. I have made changes shown
> below
> > >> and
> > >> > have done some testing with testpmd utility and now have following
> > >> questions
> > >> >
> > >> > 1. What amount of testing is required to qualify patch as
> successfully
> > >> > tested on new chipsets
> > >>
> > >> There is no good answer to this question. Generally, you must be sure
> that
> > >> you don't break anything.
> > >> So you must test the code paths you have changed.
> > >>
> > >
> > >  yes I have done testing on Ubuntu for I217 using testpmd.
> > >
> > >>
> > >> > 2. FreeBSD testing, currently we have Ubuntu 14.04 installed on
> existing
> > >> > H97N motherboard and testing is done solely on Linux. We plan to get
> > >> > another motherboard which will have I218 chipset and still deciding
> > >> whether
> > >> > to go with FreeBSD or Ubuntu. So the question I have is what amount
> of
> > >> > testing should be done on FreeBSD? I don't think
> > >> setup.sh/dpdk_nic_bind.py
> > >> > works on FreeBSD yet hence the question on testing.
> > >>
> > >> FreeBSD testing is required when patching common EAL, scripts or
> > >> makefiles.
> > >>
> > >> > >  lib/librte_pmd_e1000/e1000/e1000_api.c  | 21
> > >> +
> > >> > >  lib/librte_pmd_e1000/e1000/e1000_api.h  |  1 +
> > >> > >  lib/librte_pmd_e1000/e1000/e1000_osdep.h| 24
> > >> +++-
> > >>
> > >> These files are part of the base driver.
> > >> The rule is to not patch them and try to do the changes in PMD only.
> > >> There can be exceptions if an Intel maintainer acknowledges it.
> > >>
> > >
> > >   Changes in these files are modifying existing macros
> > >
> > > E1000_READ_FLASH_REG,
> > > E1000_WRITE_FLASH_REG
> > > ...
> > >
> > > If it is not recommended to modify these files, should I move macros
> into
> > > some PMD file?
> > >
> > > Thanks.
>
>

[dpdk-dev] Cross-compilation of bsdapp on Ubuntu

[Ravi Kerur]

Thanks folks for the information.

On Mon, Jan 12, 2015 at 5:51 AM, Neil Horman  wrote:

> On Mon, Jan 12, 2015 at 11:21:32AM +, Bruce Richardson wrote:
> > On Fri, Jan 09, 2015 at 09:14:16AM -0800, Ravi Kerur wrote:
> > > Hi,
> > >
> > > Has anyone successfully cross compiled bsdapp on Ubuntu or other linux
> > > flavor? From the Linux documentation I see
> > >
> > > "To compile all 64-bit targets using gcc, use:
> > >
> > > make install T=x86_64*gcc"
> > >
> > > which makes me believe that bsdapp can be cross-compiled.
> >
> > Actually, I think it's just that that bit got missed in the
> documentation update
> > when we added bsd support. :-)
> > I'm not aware of anyone who has successfully built a bsdapp dpdk
> application on
> > linux or vice-version.
> >
> You're not going to be able to cross compile bsd on a linux system or vice
> versa
> unless you install system level compat libs to handle all the OS-specific
> library calls.  Those exist, but its usually not worth the effort to do so.
> Just as easy/easier to install a virt guest with the appropriate operating
> system.
>
> Neil
>
> > /Bruce
> >
> > >
> > > I am trying to understand what GNU libraries and other toolchain
> > > related installation has to be done on Linux in order to get bsd
> > > successfully compiled.  Inputs appreciated.
> > >
> > > Thanks,
> > >
> > > Ravi
> >
>

[dpdk-dev] [PATCH 0/7] vmxnet3: driver enhancements

[Thomas Monjalon]

Someone to review these patches?

2014-12-16 21:13, Stephen Hemminger:
> This set of patches updates the vmxnet3 in the DPDK to match
> the features in the driver I wrote. The most important critical
> feature is support for multi-segment jumbo frames.
> 
> Stephen Hemminger (7):
>   vmxnet3: add support for VLAN filtering
>   vmxnet3: remove mtu check
>   vmxnet3: add support for mulit-segment transmit
>   vmxnet3: fix link state handling
>   vmxnet3: get rid of DEBUG ifdefs
>   vmxnet3: support RSS and refactor offload
>   vmxnet3: support jumbo frames
> 
>  lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c | 163 ++---
>  lib/librte_pmd_vmxnet3/vmxnet3_ethdev.h |   9 +-
>  lib/librte_pmd_vmxnet3/vmxnet3_ring.h   |   2 +
>  lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c   | 306 
> +---
>  4 files changed, 265 insertions(+), 215 deletions(-)

[dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network Connection' NIC cards

[ayon jyoti Biswas]

hi,
i have two* '82574L Gigabit Network Connection'*  NIC cards .
Can i run dpdk application with this interfaces .
i have binded to igb_uio . My l2forward application is successfully getting
initialized but could not receive/transmit traffic .
How can i run dpdk l2fwd application with this NIC cards .



./build/app/l2fwd -c 0x3 -n 2 -m 512 -- -p 0x3

EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f8bbaa0 (size = 0x20)
EAL: Ask a virtual area of 0xffc0 bytes
EAL: Virtual area found at 0x7f8abac0 (size = 0xffc0)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f8aba80 (size = 0x20)
EAL: Requesting 256 pages of size 2MB from socket 0
EAL: TSC frequency is ~3192736 KHz
EAL: Master core 0 is ready (tid=bb5be800)
EAL: Core 1 is ready (tid=b9ffe700)
EAL: PCI device :02:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10d3 rte_em_pmd
EAL:   PCI memory mapped at 0x7f8bb95de000
EAL:   PCI memory mapped at 0x7f8bb955e000
EAL:   PCI memory mapped at 0x7f8bb955a000
EAL: PCI device :03:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10d3 rte_em_pmd
EAL:   PCI memory mapped at 0x7f8bb953a000
EAL:   PCI memory mapped at 0x7f8bb94ba000
EAL:   PCI memory mapped at 0x7f8bb94b6000

NUMBER OF PORTS=2**
Lcore 0: RX port 0
Lcore 1: RX port 1
Initializing port 0...
 ***PORTID= 0*


./tools/pci_unbind.py --status

Network devices using IGB_UIO driver

:02:00.0 '82574L Gigabit Network Connection' drv=igb_uio unused=e1000e
:03:00.0 '82574L Gigabit Network Connection' drv=igb_uio unused=e1000e


ethtool -i eth3
driver: e1000e
version: 2.1.4-k
firmware-version: 1.8-0
bus-info: :03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

ethtool -i eth4
driver: e1000e
version: 2.1.4-k
firmware-version: 1.8-0
bus-info: :02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no


thanks
ayon

[dpdk-dev] [PATCH 3/3] unit tests add mode 4 unit test

[Thomas Monjalon]

2014-12-12 09:14, Michal Jastrzebski:
[...]
> Additionally some typos fix is included.
> 
> Signed-off-by: Pawel Wodkowski 
> ---
>  app/test/Makefile  |1 +
>  app/test/test.h|  111 +--
>  app/test/test_link_bonding.c   |2 +-
>  app/test/test_link_bonding_mode4.c | 1412 
> 

Please do not mix a test addition with a reworking of test.h.

Thanks
-- 
Thomas

[dpdk-dev] [PATCH 2/3] PMD ring MAC management, fix initialization, link up/down

[Thomas Monjalon]

2014-12-12 09:14, Michal Jastrzebski:
>   * add MAC management per device
>   * fix initialization procedure
>   * add link up/down functions
> 
> Signed-off-by: Pawel Wodkowski 
> Signed-off-by: Tomasz Kulasek 

Please, split this patch: only 1 feature per patch.

Thanks
-- 
Thomas

[dpdk-dev] Why nothing since 1.8.0?

[Thomas Monjalon]

2015-01-15 04:27, Ouyang, Changchun:
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger wrote:
> > > > Ok, so 1.8.0 came out almost a month ago and none of the patches
> > > > that were deferred waiting for the release got merged since then.
> > > > Last commit in git is the 1.8.0 release.
> > > >
> > > > Where is the post-merge window bundle, where are the later commits?
> > > > Lots of patches are sitting rotting in patchwork...
> > >
> > > +1, I've had the same questions.
> > > Neil
> > 
> > +1, Some patch set might be ready for being merged.
> 
> +1,  the earlier some patches are merged into mainline, and the easier those
> sequent patch sets can resolve their conflicts.

+1, there are some patches which are properly reviewed

Reminder: sub-tree to manage specific part of DPDK can be open on request

-- 
Thomas, back on track

[dpdk-dev] [PATCH 5/5] ethdev: remove old APIs and structures of 5tuple and 2tuple filters

[Jingjing Wu]

Following structures are removed:
 - rte_2tuple_filter
 - rte_5tuple_filter
Following APIs are removed:
 - rte_eth_dev_add_2tuple_filter
 - rte_eth_dev_remove_2tuple_filter
 - rte_eth_dev_get_2tuple_filter
 - rte_eth_dev_add_5tuple_filter
 - rte_eth_dev_remove_5tuple_filter
 - rte_eth_dev_get_5tuple_filter
It also move macros TCP_*_FLAG to rte_eth_ctrl.h, and removes the macro
TCP_UGR_FLAG which is duplicated with TCP_URG_FLAG.

Signed-off-by: Jingjing Wu 
---
 lib/librte_ether/rte_eth_ctrl.h |   7 ++
 lib/librte_ether/rte_ethdev.c   | 116 
 lib/librte_ether/rte_ethdev.h   | 195 
 3 files changed, 7 insertions(+), 311 deletions(-)

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 58d830d..ab8e9a9 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -139,6 +139,13 @@ struct rte_eth_ethertype_filter {
RTE_NTUPLE_FLAGS_DST_PORT | \
RTE_NTUPLE_FLAGS_PROTO)

+#define TCP_URG_FLAG 0x20
+#define TCP_ACK_FLAG 0x10
+#define TCP_PSH_FLAG 0x08
+#define TCP_RST_FLAG 0x04
+#define TCP_SYN_FLAG 0x02
+#define TCP_FIN_FLAG 0x01
+#define TCP_FLAG_ALL 0x3F

 /**
  * A structure used to define the ntuple filter entry
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 95f2ceb..22d76c8 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3072,122 +3072,6 @@ rte_eth_dev_get_ethertype_filter(uint8_t port_id, 
uint16_t index,
 }

 int
-rte_eth_dev_add_2tuple_filter(uint8_t port_id, uint16_t index,
-   struct rte_2tuple_filter *filter, uint16_t rx_queue)
-{
-   struct rte_eth_dev *dev;
-
-   if (port_id >= nb_ports) {
-   PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-   return -ENODEV;
-   }
-   if (filter->protocol != IPPROTO_TCP &&
-   filter->tcp_flags != 0){
-   PMD_DEBUG_TRACE("tcp flags is 0x%x, but the protocol value"
-   " is not TCP\n",
-   filter->tcp_flags);
-   return -EINVAL;
-   }
-
-   dev = &rte_eth_devices[port_id];
-   FUNC_PTR_OR_ERR_RET(*dev->dev_ops->add_2tuple_filter, -ENOTSUP);
-   return (*dev->dev_ops->add_2tuple_filter)(dev, index, filter, rx_queue);
-}
-
-int
-rte_eth_dev_remove_2tuple_filter(uint8_t port_id, uint16_t index)
-{
-   struct rte_eth_dev *dev;
-
-   if (port_id >= nb_ports) {
-   PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-   return -ENODEV;
-   }
-
-   dev = &rte_eth_devices[port_id];
-   FUNC_PTR_OR_ERR_RET(*dev->dev_ops->remove_2tuple_filter, -ENOTSUP);
-   return (*dev->dev_ops->remove_2tuple_filter)(dev, index);
-}
-
-int
-rte_eth_dev_get_2tuple_filter(uint8_t port_id, uint16_t index,
-   struct rte_2tuple_filter *filter, uint16_t *rx_queue)
-{
-   struct rte_eth_dev *dev;
-
-   if (filter == NULL || rx_queue == NULL)
-   return -EINVAL;
-
-   if (port_id >= nb_ports) {
-   PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-   return -ENODEV;
-   }
-
-   dev = &rte_eth_devices[port_id];
-   FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_2tuple_filter, -ENOTSUP);
-   return (*dev->dev_ops->get_2tuple_filter)(dev, index, filter, rx_queue);
-}
-
-int
-rte_eth_dev_add_5tuple_filter(uint8_t port_id, uint16_t index,
-   struct rte_5tuple_filter *filter, uint16_t rx_queue)
-{
-   struct rte_eth_dev *dev;
-
-   if (port_id >= nb_ports) {
-   PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-   return -ENODEV;
-   }
-
-   if (filter->protocol != IPPROTO_TCP &&
-   filter->tcp_flags != 0){
-   PMD_DEBUG_TRACE("tcp flags is 0x%x, but the protocol value"
-   " is not TCP\n",
-   filter->tcp_flags);
-   return -EINVAL;
-   }
-
-   dev = &rte_eth_devices[port_id];
-   FUNC_PTR_OR_ERR_RET(*dev->dev_ops->add_5tuple_filter, -ENOTSUP);
-   return (*dev->dev_ops->add_5tuple_filter)(dev, index, filter, rx_queue);
-}
-
-int
-rte_eth_dev_remove_5tuple_filter(uint8_t port_id, uint16_t index)
-{
-   struct rte_eth_dev *dev;
-
-   if (port_id >= nb_ports) {
-   PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
-   return -ENODEV;
-   }
-
-   dev = &rte_eth_devices[port_id];
-   FUNC_PTR_OR_ERR_RET(*dev->dev_ops->remove_5tuple_filter, -ENOTSUP);
-   return (*dev->dev_ops->remove_5tuple_filter)(dev, index);
-}
-
-int
-rte_eth_dev_get_5tuple_filter(uint8_t port_id, uint16_t index,
-   struct rte_5tuple_filter *filter, uint16_t *rx_queue)
-{
-   struct rte_eth_dev *dev;
-
-   if (filter == NULL || rx_queue == NULL)
-   return -EINVAL;
-
-   if (port_id >= nb_ports) {
-   

[dpdk-dev] [PATCH 4/5] testpmd: new commands for ntuple filter

[Jingjing Wu]

Following commands of 5tuple and 2tuple filter are removed:
 - add_2tuple_filter (port_id) protocol (pro_value) (pro_mask)
   dst_port (port_value) (port_mask) flags (flg_value) priority (prio
   queue (queue_id) index (idx)
 - remove_2tuple_filter (port_id) index (idx)
 - get_2tuple_filter (port_id) index (idx)
 - add_5tuple_filter (port_id) dst_ip (dst_address) src_ip (src_addres
   dst_port (dst_port_value) src_port (src_port_value) protocol (prot
   mask (mask_value) flags (flags_value) priority (prio_value)"
   queue (queue_id) index (idx)
 - remove_5tuple_filter (port_id) index (idx)
 - get_5tuple_filter (port_id) index (idx)

New commands are added for 5tuple and 2tuple filter by using filter_ctrl API
and new ntuple filter structure:
 - 2tuple_filter (port_id) (add|del)
   dst_port (dst_port_value) protocol (protocol_value)
   mask (mask_value) tcp_flags (tcp_flags_value)
   priority (prio_value) queue (queue_id)
 - 5tuple_filter (port_id) (add|del)
   dst_ip (dst_address) src_ip (src_address)
   dst_port (dst_port_value) src_port (src_port_value)
   protocol (protocol_value)
   mask (mask_value) tcp_flags (tcp_flags_value)
   priority (prio_value) queue (queue_id)

Signed-off-by: Jingjing Wu 
---
 app/test-pmd/cmdline.c | 406 ++---
 app/test-pmd/config.c  |  65 
 2 files changed, 186 insertions(+), 285 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 882a5a2..1d74870 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -664,28 +664,19 @@ static void cmd_help_long_parsed(void *parsed_result,
"get_ethertype_filter (port_id) index (idx)\n"
"get info of a ethertype filter.\n\n"

-   "add_2tuple_filter (port_id) protocol (pro_value) 
(pro_mask)"
-   " dst_port (port_value) (port_mask) flags (flg_value) 
priority (prio_value)"
-   " queue (queue_id) index (idx)\n"
-   "add a 2tuple filter.\n\n"
-
-   "remove_2tuple_filter (port_id) index (idx)\n"
-   "remove a 2tuple filter.\n\n"
-
-   "get_2tuple_filter (port_id) index (idx)\n"
-   "get info of a 2tuple filter.\n\n"
-
-   "add_5tuple_filter (port_id) dst_ip (dst_address) 
src_ip (src_address)"
-   " dst_port (dst_port_value) src_port (src_port_value) 
protocol (protocol_value)"
-   " mask (mask_value) flags (flags_value) priority 
(prio_value)"
-   " queue (queue_id) index (idx)\n"
-   "add a 5tuple filter.\n\n"
-
-   "remove_5tuple_filter (port_id) index (idx)\n"
-   "remove a 5tuple filter.\n\n"
-
-   "get_5tuple_filter (port_id) index (idx)\n"
-   "get info of a 5tuple filter.\n\n"
+   "2tuple_filter (port_id) (add|del)"
+   " dst_port (dst_port_value) protocol (protocol_value)"
+   " mask (mask_value) tcp_flags (tcp_flags_value)"
+   " priority (prio_value) queue (queue_id)\n"
+   "Add/Del a 2tuple filter.\n\n"
+
+   "5tuple_filter (port_id) (add|del)"
+   " dst_ip (dst_address) src_ip (src_address)"
+   " dst_port (dst_port_value) src_port (src_port_value)"
+   " protocol (protocol_value)"
+   " mask (mask_value) tcp_flags (tcp_flags_value)"
+   " priority (prio_value) queue (queue_id)\n"
+   "Add/Del a 5tuple filter.\n\n"

"add_syn_filter (port_id) priority (high|low) queue 
(queue_id)"
"add syn filter.\n\n"
@@ -7491,21 +7482,20 @@ cmdline_parse_inst_t cmd_get_syn_filter = {
 /* *** ADD/REMOVE A 2tuple FILTER *** */
 struct cmd_2tuple_filter_result {
cmdline_fixed_string_t filter;
-   uint8_t port_id;
-   cmdline_fixed_string_t protocol;
-   uint8_t protocol_value;
-   uint8_t protocol_mask;
+   uint8_t  port_id;
+   cmdline_fixed_string_t ops;
cmdline_fixed_string_t dst_port;
uint16_t dst_port_value;
-   uint16_t dst_port_mask;
-   cmdline_fixed_string_t flags;
-   uint8_t flags_value;
+   cmdline_fixed_string_t protocol;
+   uint8_t protocol_value;
+   cmdline_fixed_string_t mask;
+   uint8_t  mask_value;
+   cmdline_fixed_string_t tcp_flags;
+   uint8_t tcp_flags_value;
cmdline_fixed_string_t priority;
-   uint8_t priority_value;
+   uint8_t  priority_value;
cmdline_fixed_string_t queue;
-   uint16_t queue_id;
-   cmdline_fixed_string_t index;
-   uint16_t index_value;
+   uint16_t  queue_id;
 };

 static void
@@ -7513,59 +

[dpdk-dev] [PATCH 3/5] e1000: ntuple filter functions replace old ones for 2tuple and 5tuple filter

[Jingjing Wu]

This patch defines new functions dealing with ntuple filters which is
corresponding to 2tuple filter for 82580 and i350 in HW, and to 5tuple
filter for 82576 in HW.
It removes old functions which deal with 2tuple and 5tuple filters in igb 
driver.
It also defines eth_igb_filter_ctrl which is binding to filter_ctrl API,
and ntuple filter can be dealt with through this new entrance.

Signed-off-by: Jingjing Wu 
---
 lib/librte_pmd_e1000/e1000_ethdev.h |  79 +++-
 lib/librte_pmd_e1000/igb_ethdev.c   | 892 +---
 2 files changed, 680 insertions(+), 291 deletions(-)

diff --git a/lib/librte_pmd_e1000/e1000_ethdev.h 
b/lib/librte_pmd_e1000/e1000_ethdev.h
index 71eb5fb..2433759 100644
--- a/lib/librte_pmd_e1000/e1000_ethdev.h
+++ b/lib/librte_pmd_e1000/e1000_ethdev.h
@@ -67,14 +67,6 @@

 #define E1000_IMIR_DSTPORT 0x
 #define E1000_IMIR_PRIORITY0xE000
-#define E1000_IMIR_EXT_SIZE_BP 0x1000
-#define E1000_IMIR_EXT_CTRL_UGR0x2000
-#define E1000_IMIR_EXT_CTRL_ACK0x4000
-#define E1000_IMIR_EXT_CTRL_PSH0x8000
-#define E1000_IMIR_EXT_CTRL_RST0x0001
-#define E1000_IMIR_EXT_CTRL_SYN0x0002
-#define E1000_IMIR_EXT_CTRL_FIN0x0004
-#define E1000_IMIR_EXT_CTRL_BP 0x0008
 #define E1000_MAX_TTQF_FILTERS 8
 #define E1000_2TUPLE_MAX_PRI   7

@@ -96,11 +88,6 @@
 #define E1000_MAX_FTQF_FILTERS   8
 #define E1000_FTQF_PROTOCOL_MASK 0x00FF
 #define E1000_FTQF_5TUPLE_MASK_SHIFT 28
-#define E1000_FTQF_PROTOCOL_COMP_MASK0x1000
-#define E1000_FTQF_SOURCE_ADDR_MASK  0x2000
-#define E1000_FTQF_DEST_ADDR_MASK0x4000
-#define E1000_FTQF_SOURCE_PORT_MASK  0x8000
-#define E1000_FTQF_VF_MASK_EN0x8000
 #define E1000_FTQF_QUEUE_MASK0x03ff
 #define E1000_FTQF_QUEUE_SHIFT   16
 #define E1000_FTQF_QUEUE_ENABLE  0x0100
@@ -131,6 +118,68 @@ struct e1000_vf_info {
uint16_t tx_rate;
 };

+TAILQ_HEAD(e1000_5tuple_filter_list, e1000_5tuple_filter);
+TAILQ_HEAD(e1000_2tuple_filter_list, e1000_2tuple_filter);
+
+struct e1000_5tuple_filter_info {
+   uint32_t dst_ip;
+   uint32_t src_ip;
+   uint16_t dst_port;
+   uint16_t src_port;
+   uint8_t proto;   /* l4 protocol. */
+   /* the packet matched above 5tuple and contain any set bit will hit 
this filter. */
+   uint8_t tcp_flags;
+   uint8_t priority;/* seven levels (001b-111b), 111b is highest,
+ used when more than one filter matches. */
+   uint8_t dst_ip_mask:1,   /* if mask is 1b, do not compare dst ip. */
+   src_ip_mask:1,   /* if mask is 1b, do not compare src ip. */
+   dst_port_mask:1, /* if mask is 1b, do not compare dst port. */
+   src_port_mask:1, /* if mask is 1b, do not compare src port. */
+   proto_mask:1;/* if mask is 1b, do not compare protocol. */
+};
+
+struct e1000_2tuple_filter_info {
+   uint16_t dst_port;
+   uint8_t proto;   /* l4 protocol. */
+   /* the packet matched above 2tuple and contain any set bit will hit 
this filter. */
+   uint8_t tcp_flags;
+   uint8_t priority;/* seven levels (001b-111b), 111b is highest,
+ used when more than one filter matches. */
+   uint8_t dst_ip_mask:1,   /* if mask is 1b, do not compare dst ip. */
+   src_ip_mask:1,   /* if mask is 1b, do not compare src ip. */
+   dst_port_mask:1, /* if mask is 1b, do not compare dst port. */
+   src_port_mask:1, /* if mask is 1b, do not compare src port. */
+   proto_mask:1;/* if mask is 1b, do not compare protocol. */
+};
+
+/* 5tuple filter structure */
+struct e1000_5tuple_filter {
+   TAILQ_ENTRY(e1000_5tuple_filter) entries;
+   uint16_t index;   /* the index of 5tuple filter */
+   struct e1000_5tuple_filter_info filter_info;
+   uint16_t queue;   /* rx queue assigned to */
+};
+
+/* 2tuple filter structure */
+struct e1000_2tuple_filter {
+   TAILQ_ENTRY(e1000_2tuple_filter) entries;
+   uint16_t index; /* the index of 2tuple filter */
+   struct e1000_2tuple_filter_info filter_info;
+   uint16_t queue;   /* rx queue assigned to */
+};
+
+/*
+ * Structure to store filters' info.
+ */
+struct e1000_filter_info {
+   /* Bit mask for every used 5tuple filter */
+   uint8_t fivetuple_mask;
+   struct e1000_5tuple_filter_list fivetuple_list;
+   /* Bit mask for every used 2tuple filter */
+   uint8_t twotuple_mask;
+   struct e1000_2tuple_filter_list twotuple_list;
+};
+
 /*
  * Structure to store private data for each driver instance (for each port).
  */
@@ -140,6 +189,7 @@ struct e1000_adapter {
struct e1000_interrupt  intr;
struct e1000_vfta   shadow_v

[dpdk-dev] [PATCH 2/5] ixgbe: ntuple filter functions replace old ones for 5tuple filter

[Jingjing Wu]

This patch defines new functions dealing with ntuple filters which is
corresponding to 5tuple in HW.
It removes old functions which deal with 5tuple filters.
It also defines ixgbe_dev_filter_ctrl which is binding to filter_ctrl API,
and ntuple filter can be dealt with through this new entrance.

Signed-off-by: Jingjing Wu 
---
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 489 +++-
 lib/librte_pmd_ixgbe/ixgbe_ethdev.h |  62 -
 2 files changed, 421 insertions(+), 130 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index 3fc3738..02a6be1 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -237,13 +237,22 @@ static int ixgbe_remove_ethertype_filter(struct 
rte_eth_dev *dev,
uint16_t index);
 static int ixgbe_get_ethertype_filter(struct rte_eth_dev *dev, uint16_t index,
struct rte_ethertype_filter *filter, uint16_t 
*rx_queue);
-static int ixgbe_add_5tuple_filter(struct rte_eth_dev *dev, uint16_t index,
-   struct rte_5tuple_filter *filter, uint16_t rx_queue);
-static int ixgbe_remove_5tuple_filter(struct rte_eth_dev *dev,
-   uint16_t index);
-static int ixgbe_get_5tuple_filter(struct rte_eth_dev *dev, uint16_t index,
-   struct rte_5tuple_filter *filter, uint16_t *rx_queue);
-
+static int ixgbe_add_5tuple_filter(struct rte_eth_dev *dev,
+   struct ixgbe_5tuple_filter *filter);
+static void ixgbe_remove_5tuple_filter(struct rte_eth_dev *dev,
+   struct ixgbe_5tuple_filter *filter);
+static int ixgbe_add_del_ntuple_filter(struct rte_eth_dev *dev,
+   struct rte_eth_ntuple_filter *filter,
+   bool add);
+static int ixgbe_ntuple_filter_handle(struct rte_eth_dev *dev,
+   enum rte_filter_op filter_op,
+   void *arg);
+static int ixgbe_get_ntuple_filter(struct rte_eth_dev *dev,
+   struct rte_eth_ntuple_filter *filter);
+static int ixgbe_dev_filter_ctrl(struct rte_eth_dev *dev,
+enum rte_filter_type filter_type,
+enum rte_filter_op filter_op,
+void *arg);
 static int ixgbevf_dev_set_mtu(struct rte_eth_dev *dev, uint16_t mtu);

 /*
@@ -383,9 +392,7 @@ static struct eth_dev_ops ixgbe_eth_dev_ops = {
.add_ethertype_filter= ixgbe_add_ethertype_filter,
.remove_ethertype_filter = ixgbe_remove_ethertype_filter,
.get_ethertype_filter= ixgbe_get_ethertype_filter,
-   .add_5tuple_filter   = ixgbe_add_5tuple_filter,
-   .remove_5tuple_filter= ixgbe_remove_5tuple_filter,
-   .get_5tuple_filter   = ixgbe_get_5tuple_filter,
+   .filter_ctrl = ixgbe_dev_filter_ctrl,
 };

 /*
@@ -732,6 +739,8 @@ eth_ixgbe_dev_init(__attribute__((unused)) struct 
eth_driver *eth_drv,
IXGBE_DEV_PRIVATE_TO_HWSTRIP_BITMAP(eth_dev->data->dev_private);
struct ixgbe_dcb_config *dcb_config =
IXGBE_DEV_PRIVATE_TO_DCB_CFG(eth_dev->data->dev_private);
+   struct ixgbe_filter_info *filter_info =
+   IXGBE_DEV_PRIVATE_TO_FILTER_INFO(eth_dev->data->dev_private);
uint32_t ctrl_ext;
uint16_t csum;
int diag, i;
@@ -913,6 +922,11 @@ eth_ixgbe_dev_init(__attribute__((unused)) struct 
eth_driver *eth_drv,
/* enable support intr */
ixgbe_enable_intr(eth_dev);

+   /* initialize 5tuple filter list */
+   TAILQ_INIT(&filter_info->fivetuple_list);
+   memset(filter_info->fivetuple_mask, 0,
+   sizeof(uint32_t) * IXGBE_5TUPLE_ARRAY_SIZE);
+
return 0;
 }

@@ -1602,6 +1616,9 @@ ixgbe_dev_stop(struct rte_eth_dev *dev)
IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct ixgbe_vf_info *vfinfo =
*IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private);
+   struct ixgbe_filter_info *filter_info =
+   IXGBE_DEV_PRIVATE_TO_FILTER_INFO(dev->data->dev_private);
+   struct ixgbe_5tuple_filter *p_5tuple, *p_5tuple_next;
int vf;

PMD_INIT_FUNC_TRACE();
@@ -1631,6 +1648,18 @@ ixgbe_dev_stop(struct rte_eth_dev *dev)
/* Clear recorded link status */
memset(&link, 0, sizeof(link));
rte_ixgbe_dev_atomic_write_link_status(dev, &link);
+
+   /* Remove all ntuple filters of the device */
+   for (p_5tuple = TAILQ_FIRST(&filter_info->fivetuple_list);
+p_5tuple != NULL; p_5tuple = p_5tuple_next) {
+   p_5tuple_next = TAILQ_NEXT(p_5tuple, entries);
+   TAILQ_REMOVE(&filter_info->fivetuple_list,
+p_5tuple, entries);
+   rte_free(p_5tuple);
+   }
+   memset(filter_info->fivetuple_mask, 0,
+   sizeof(uint32_t) * IXGBE_5TUPLE_ARRAY_SIZE);
+
 }

 /*
@@ -3933,62 +

[dpdk-dev] [PATCH 1/5] ethdev: define ntuple filter type and its structure

[Jingjing Wu]

This patch defines ntuple filter type RTE_ETH_FILTER_NTUPLE and its structure 
rte_eth_ntuple_filter.
It also corrects the typo TCP_UGR_FLAG to TCP_URG_FLAG

Signed-off-by: Jingjing Wu 
---
 lib/librte_ether/rte_eth_ctrl.h | 50 +
 lib/librte_ether/rte_ethdev.h   |  2 ++
 2 files changed, 52 insertions(+)

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 5d9c387..58d830d 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -53,6 +53,7 @@ enum rte_filter_type {
RTE_ETH_FILTER_NONE = 0,
RTE_ETH_FILTER_MACVLAN,
RTE_ETH_FILTER_ETHERTYPE,
+   RTE_ETH_FILTER_NTUPLE,
RTE_ETH_FILTER_TUNNEL,
RTE_ETH_FILTER_FDIR,
RTE_ETH_FILTER_MAX
@@ -117,6 +118,55 @@ struct rte_eth_ethertype_filter {
 };

 /**
+ * Define all structures for ntuple Filter type.
+ */
+
+#define RTE_NTUPLE_FLAGS_DST_IP0x0001 /**< If set, dst_ip is part of 
ntuple */
+#define RTE_NTUPLE_FLAGS_SRC_IP0x0002 /**< If set, src_ip is part of 
ntuple */
+#define RTE_NTUPLE_FLAGS_DST_PORT  0x0004 /**< If set, dst_port is part of 
ntuple */
+#define RTE_NTUPLE_FLAGS_SRC_PORT  0x0008 /**< If set, src_port is part of 
ntuple */
+#define RTE_NTUPLE_FLAGS_PROTO 0x0010 /**< If set, protocol is part of 
ntuple */
+#define RTE_NTUPLE_FLAGS_TCP_FLAG  0x0020 /**< If set, tcp flag is involved */
+
+#define RTE_5TUPLE_FLAGS ( \
+   RTE_NTUPLE_FLAGS_DST_IP | \
+   RTE_NTUPLE_FLAGS_SRC_IP | \
+   RTE_NTUPLE_FLAGS_DST_PORT | \
+   RTE_NTUPLE_FLAGS_SRC_PORT | \
+   RTE_NTUPLE_FLAGS_PROTO)
+
+#define RTE_2TUPLE_FLAGS ( \
+   RTE_NTUPLE_FLAGS_DST_PORT | \
+   RTE_NTUPLE_FLAGS_PROTO)
+
+
+/**
+ * A structure used to define the ntuple filter entry
+ * to support RTE_ETH_FILTER_NTUPLE with RTE_ETH_FILTER_ADD,
+ * RTE_ETH_FILTER_DELETE and RTE_ETH_FILTER_GET operations.
+ */
+struct rte_eth_ntuple_filter {
+   uint16_t flags;  /**< Flags from RTE_NTUPLE_FLAGS_* */
+   uint32_t dst_ip; /**< Destination IP address in big endian. */
+   uint32_t dst_ip_mask;/**< Mask of destination IP address. */
+   uint32_t src_ip; /**< Source IP address in big endian. */
+   uint32_t src_ip_mask;/**< Mask of destination IP address. */
+   uint16_t dst_port;   /**< Destination port in big endian. */
+   uint16_t dst_port_mask;  /**< Mask of destination port. */
+   uint16_t src_port;   /**< Source Port in big endian. */
+   uint16_t src_port_mask;  /**< Mask of source port. */
+   uint8_t proto;   /**< L4 protocol. */
+   uint8_t proto_mask;  /**< Mask of L4 protocol. */
+   /** tcp_flags only meaningful when the proto is TCP.
+   The packet matched above ntuple fields and contain
+   any set bit in tcp_flags will hit this filter. */
+   uint8_t tcp_flags;
+   uint16_t priority;   /**< seven levels (001b-111b), 111b is highest,
+ used when more than one filter matches. */
+   uint16_t queue;  /**< Queue assigned to when match*/
+};
+
+/**
  * Tunneled type.
  */
 enum rte_eth_tunnel_type {
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index ce0528f..551b28f 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -963,6 +963,8 @@ struct rte_eth_dev_callback;
 /** @internal Structure to keep track of registered callbacks */
 TAILQ_HEAD(rte_eth_dev_cb_list, rte_eth_dev_callback);

+
+#define TCP_URG_FLAG 0x20
 #define TCP_UGR_FLAG 0x20
 #define TCP_ACK_FLAG 0x10
 #define TCP_PSH_FLAG 0x08
-- 
1.9.3

[dpdk-dev] [PATCH 0/5] new ntuple filter replaces 2tuple and 5tuple filters

[Jingjing Wu]

The patch set uses new filter_ctrl API to replace old 2tuple and 5tuple filter 
APIs.
It defines ntuple filter to combine 2tuple and 5tuple types. 
It uses new functions and structure to replace old ones in igb/ixgbe driver,
new commands to replace old ones in testpmd, and removes the old APIs.
It removes the filter's index parameters from user interface, only the
filter's key and assigned queue are visible to user.

Jingjing Wu (5):
  ethdev: define ntuple filter type and its structure
  ixgbe: ntuple filter functions replace old ones for 5tuple filter
  e1000: ntuple filter functions replace old ones for 2tuple and 5tuple
filter
  testpmd: new commands for ntuple filter
  ethdev: remove old APIs and structures of 5tuple and 2tuple filters

 app/test-pmd/cmdline.c  | 406 
 app/test-pmd/config.c   |  65 ---
 lib/librte_ether/rte_eth_ctrl.h |  57 +++
 lib/librte_ether/rte_ethdev.c   | 116 -
 lib/librte_ether/rte_ethdev.h   | 193 
 lib/librte_pmd_e1000/e1000_ethdev.h |  79 +++-
 lib/librte_pmd_e1000/igb_ethdev.c   | 892 +---
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 489 +++-
 lib/librte_pmd_ixgbe/ixgbe_ethdev.h |  62 ++-
 9 files changed, 1344 insertions(+), 1015 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH 22/22] virtio: Use soft vlan strip in mergeable Rx path

[Stephen Hemminger]

On Thu, 15 Jan 2015 13:15:30 +0800
Ouyang Changchun  wrote:

> To keep the consistent logic with normal Rx path, the mergeable
> Rx path also needs software vlan strip/decap if it is enabled.
> 
> Signed-off-by: Changchun Ouyang 
> ---
>  lib/librte_pmd_virtio/virtio_rxtx.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
> b/lib/librte_pmd_virtio/virtio_rxtx.c
> index 2529dc4..9090613 100644
> --- a/lib/librte_pmd_virtio/virtio_rxtx.c
> +++ b/lib/librte_pmd_virtio/virtio_rxtx.c
> @@ -568,6 +568,7 @@ virtio_recv_mergeable_pkts(void *rx_queue,
>   uint16_t nb_pkts)
>  {
>   struct virtqueue *rxvq = rx_queue;
> + struct virtio_hw *hw = rxvq->hw;
>   struct rte_mbuf *rxm, *new_mbuf;
>   uint16_t nb_used, num, nb_rx = 0;
>   uint32_t len[VIRTIO_MBUF_BURST_SZ];
> @@ -674,6 +675,9 @@ virtio_recv_mergeable_pkts(void *rx_queue,
>   seg_res -= rcv_cnt;
>   }
>  
> + if (hw->vlan_strip)
> + rte_vlan_strip(rx_pkts[nb_rx]);
> +
>   VIRTIO_DUMP_PACKET(rx_pkts[nb_rx],
>   rx_pkts[nb_rx]->data_len);
>  

If you resubmit, just combine this with earlier patch that does vlan strip

[dpdk-dev] [PATCH 18/22] virtio: Fix descriptor index issue

[Stephen Hemminger]

On Thu, 15 Jan 2015 13:15:26 +0800
Ouyang Changchun  wrote:

> It should use vring descriptor index instead of used_ring index to index 
> vq_descx.
> 
> Signed-off-by: Changchun Ouyang 
> ---
>  lib/librte_pmd_virtio/virtio_rxtx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c 
> b/lib/librte_pmd_virtio/virtio_rxtx.c
> index 12c2310..2529dc4 100644
> --- a/lib/librte_pmd_virtio/virtio_rxtx.c
> +++ b/lib/librte_pmd_virtio/virtio_rxtx.c
> @@ -144,9 +144,9 @@ virtio_xmit_cleanup(struct virtqueue *vq, uint16_t num)
>  
>   used_idx = (uint16_t)(vq->vq_used_cons_idx & (vq->vq_nentries - 
> 1));
>   uep = &vq->vq_ring.used->ring[used_idx];
> - dxp = &vq->vq_descx[used_idx];
>  
>   desc_idx = (uint16_t) uep->id;
> + dxp = &vq->vq_descx[desc_idx];
>   vq->vq_used_cons_idx++;
>   vq_ring_free_chain(vq, desc_idx);
>  

Rather than patching a code added by earlier patch in series, why
not just fix/merge the two patches?

[dpdk-dev] Why nothing since 1.8.0?

[Neil Horman]

On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote:
> 2015-01-15 04:27, Ouyang, Changchun:
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > > > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger wrote:
> > > > > Ok, so 1.8.0 came out almost a month ago and none of the patches
> > > > > that were deferred waiting for the release got merged since then.
> > > > > Last commit in git is the 1.8.0 release.
> > > > >
> > > > > Where is the post-merge window bundle, where are the later commits?
> > > > > Lots of patches are sitting rotting in patchwork...
> > > >
> > > > +1, I've had the same questions.
> > > > Neil
> > > 
> > > +1, Some patch set might be ready for being merged.
> > 
> > +1,  the earlier some patches are merged into mainline, and the easier those
> > sequent patch sets can resolve their conflicts.
> 
> +1, there are some patches which are properly reviewed
> 
> Reminder: sub-tree to manage specific part of DPDK can be open on request
> 
Ok, I think what you're saying here is you're too busy to handle all the patches
comming in at the moment.  As such I'd like to propose a sub-tree encompassing
all the pmds in DPDK.  I would envision that including all the acutal pmd's in
the tree, as well as the infrastructure that is used to interface them to the
core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the patch pool
and send you pull requests.

If you could set me up with a login to dpdk.org, I'd appreciate it.

Thanks!
Neil

> -- 
> Thomas, back on track
> 

[dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network Connection' NIC cards

[Zhang, Helin]

Hi Ayon

Good to see that!
DPDK just has only one driver of igb_uio to bind NICs. VFIO is another story. 
You don?t have choices.

Please read the online documents for more details and steps of using DPDK!

Regards,
Helin

From: ayon jyoti Biswas [mailto:ajbiswas2...@gmail.com]
Sent: Thursday, January 15, 2015 3:31 PM
To: Zhang, Helin
Subject: Re: [dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network 
Connection' NIC cards

hi,
its OK, which driver i need to bind to this NIC??
./lib/librte_pmd_e1000/e1000/e1000_hw.h:95:
#define E1000_DEV_ID_82574L 0x10D3
Regards.

On Thu, Jan 15, 2015 at 12:54 PM, Zhang, Helin mailto:helin.zhang at intel.com>> wrote:
Hi Ayon

1521 is the device ID of my NIC, yours is 10d3. So you need to check if 10d3 is 
listed in that file or not, but not checking 1521.

Regards,
Helin

From: ayon jyoti Biswas [mailto:ajbiswas2009 at 
gmail.com]
Sent: Thursday, January 15, 2015 3:19 PM
To: Zhang, Helin
Subject: Re: [dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network 
Connection' NIC cards

hi,

lspci -nn | grep Eth
02:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network 
Connection [8086:10d3]
03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network 
Connection [8086:10d3]
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 06)
and in ./x86_64-default-linuxapp-gcc/include/rte_pci_dev_ids.h

#define E1000_DEV_ID_I350_COPPER0x1521
is present.
regards,
Ayon

On Thu, Jan 15, 2015 at 12:11 PM, Zhang, Helin mailto:helin.zhang at intel.com>> wrote:
Check the device ID can know if your NIC is supported by dpdk or not.

"Lspci -nn | grep Eth" will show like below, 1521 is the device ID.
04:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
Connection [8086:1521]
Then check rte_pci_dev_ids.h to see if that device ID is listed in that file or 
not, then you know if your NIC is supported or not.

Regards,
Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On 
> Behalf Of ayon jyoti Biswas
> Sent: Thursday, January 15, 2015 2:29 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network
> Connection' NIC cards
>
> hi,
> i have two* '82574L Gigabit Network Connection'*  NIC cards .
> Can i run dpdk application with this interfaces .
> i have binded to igb_uio . My l2forward application is successfully getting
> initialized but could not receive/transmit traffic .
> How can i run dpdk l2fwd application with this NIC cards .
>
>
>
> ./build/app/l2fwd -c 0x3 -n 2 -m 512 -- -p 0x3
>
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7f8bbaa0 (size = 0x20)
> EAL: Ask a virtual area of 0xffc0 bytes
> EAL: Virtual area found at 0x7f8abac0 (size = 0xffc0)
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7f8aba80 (size = 0x20)
> EAL: Requesting 256 pages of size 2MB from socket 0
> EAL: TSC frequency is ~3192736 KHz
> EAL: Master core 0 is ready (tid=bb5be800)
> EAL: Core 1 is ready (tid=b9ffe700)
> EAL: PCI device :02:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10d3 rte_em_pmd
> EAL:   PCI memory mapped at 0x7f8bb95de000
> EAL:   PCI memory mapped at 0x7f8bb955e000
> EAL:   PCI memory mapped at 0x7f8bb955a000
> EAL: PCI device :03:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10d3 rte_em_pmd
> EAL:   PCI memory mapped at 0x7f8bb953a000
> EAL:   PCI memory mapped at 0x7f8bb94ba000
> EAL:   PCI memory mapped at 0x7f8bb94b6000
>
> NUMBER OF PORTS=2**
> Lcore 0: RX port 0
> Lcore 1: RX port 1
> Initializing port 0...
>  ***PORTID= 0*
>
>
> ./tools/pci_unbind.py --status
>
> Network devices using IGB_UIO driver
> 
> :02:00.0 '82574L Gigabit Network Connection' drv=igb_uio
> unused=e1000e
> :03:00.0 '82574L Gigabit Network Connection' drv=igb_uio
> unused=e1000e
>
>
> ethtool -i eth3
> driver: e1000e
> version: 2.1.4-k
> firmware-version: 1.8-0
> bus-info: :03:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
>
> ethtool -i eth4
> driver: e1000e
> version: 2.1.4-k
> firmware-version: 1.8-0
> bus-info: :02:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
>
>
> thanks
> ayon

[dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network Connection' NIC cards

[Zhang, Helin]

Hi Ayon

1521 is the device ID of my NIC, yours is 10d3. So you need to check if 10d3 is 
listed in that file or not, but not checking 1521.

Regards,
Helin

From: ayon jyoti Biswas [mailto:ajbiswas2...@gmail.com]
Sent: Thursday, January 15, 2015 3:19 PM
To: Zhang, Helin
Subject: Re: [dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network 
Connection' NIC cards

hi,

lspci -nn | grep Eth
02:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network 
Connection [8086:10d3]
03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network 
Connection [8086:10d3]
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 06)
and in ./x86_64-default-linuxapp-gcc/include/rte_pci_dev_ids.h

#define E1000_DEV_ID_I350_COPPER0x1521
is present.
regards,
Ayon

On Thu, Jan 15, 2015 at 12:11 PM, Zhang, Helin mailto:helin.zhang at intel.com>> wrote:
Check the device ID can know if your NIC is supported by dpdk or not.

"Lspci -nn | grep Eth" will show like below, 1521 is the device ID.
04:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
Connection [8086:1521]
Then check rte_pci_dev_ids.h to see if that device ID is listed in that file or 
not, then you know if your NIC is supported or not.

Regards,
Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On 
> Behalf Of ayon jyoti Biswas
> Sent: Thursday, January 15, 2015 2:29 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network
> Connection' NIC cards
>
> hi,
> i have two* '82574L Gigabit Network Connection'*  NIC cards .
> Can i run dpdk application with this interfaces .
> i have binded to igb_uio . My l2forward application is successfully getting
> initialized but could not receive/transmit traffic .
> How can i run dpdk l2fwd application with this NIC cards .
>
>
>
> ./build/app/l2fwd -c 0x3 -n 2 -m 512 -- -p 0x3
>
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7f8bbaa0 (size = 0x20)
> EAL: Ask a virtual area of 0xffc0 bytes
> EAL: Virtual area found at 0x7f8abac0 (size = 0xffc0)
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7f8aba80 (size = 0x20)
> EAL: Requesting 256 pages of size 2MB from socket 0
> EAL: TSC frequency is ~3192736 KHz
> EAL: Master core 0 is ready (tid=bb5be800)
> EAL: Core 1 is ready (tid=b9ffe700)
> EAL: PCI device :02:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10d3 rte_em_pmd
> EAL:   PCI memory mapped at 0x7f8bb95de000
> EAL:   PCI memory mapped at 0x7f8bb955e000
> EAL:   PCI memory mapped at 0x7f8bb955a000
> EAL: PCI device :03:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10d3 rte_em_pmd
> EAL:   PCI memory mapped at 0x7f8bb953a000
> EAL:   PCI memory mapped at 0x7f8bb94ba000
> EAL:   PCI memory mapped at 0x7f8bb94b6000
>
> NUMBER OF PORTS=2**
> Lcore 0: RX port 0
> Lcore 1: RX port 1
> Initializing port 0...
>  ***PORTID= 0*
>
>
> ./tools/pci_unbind.py --status
>
> Network devices using IGB_UIO driver
> 
> :02:00.0 '82574L Gigabit Network Connection' drv=igb_uio
> unused=e1000e
> :03:00.0 '82574L Gigabit Network Connection' drv=igb_uio
> unused=e1000e
>
>
> ethtool -i eth3
> driver: e1000e
> version: 2.1.4-k
> firmware-version: 1.8-0
> bus-info: :03:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
>
> ethtool -i eth4
> driver: e1000e
> version: 2.1.4-k
> firmware-version: 1.8-0
> bus-info: :02:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
>
>
> thanks
> ayon

[dpdk-dev] Fast Path Query

[Zhang, Helin]

Hi Deepak

I got it. Thanks for the detailed explanation!
The performance of packet IO shouldn?t be affected from DPDK side as long as 
enough cpu cycles can be used. While you cannot expect too much high 
performance number transmitted from kernel space to user space, as kernel stack 
or netdev framework might be bottle necks.

Regards,
Helin

From: Deepak Sehrawat [mailto:d.sehra...@gmail.com]
Sent: Wednesday, January 14, 2015 4:37 PM
To: Zhang, Helin
Subject: Re: [dpdk-dev] Fast Path Query


Hi Helin,

Let me elaborate my case a bit. Consider that Linux is controlling a  NIC port 
which is receiving Control as well as Data packets. These control packets are 
processed by a normal Linux userspace application; whereas the data packets are 
forwarded to DPDK userplane application using KNI (i.e from Linux kernel to 
DPDK). This userplane application, after processing these data packets, 
forwards them out (using PMD) of another NIC port (controlled by DPDK PMD).

Thanks,
Deepak
On Wed, Jan 14, 2015 at 1:46 PM, Zhang, Helin mailto:helin.zhang at intel.com>> wrote:
Hi Deepak

Still a bit confused. Linux driver is controlling the NIC port, are there any 
other ports controlled by DPDK? I guess yes.
If yes, there must have one or more user space thread who is responsible for 
packet exchanging between kernel and user space via exception_path or KNI. 
Packet IO speed can be still the maximum, depends on what percentage of cpu 
cycles can be used for packet IO.
Performance may or may not be affected depends on if there are enough cpu 
cycles can be used for packet IO.

Regards,
Helin

From: Deepak Sehrawat [mailto:d.sehrawat at 
gmail.com]
Sent: Wednesday, January 14, 2015 4:08 PM
To: Zhang, Helin

Subject: Re: [dpdk-dev] Fast Path Query


Hi Helin,

My mistake, I was actually refering to the case when Linux is controlling the 
NIC port (and not DPDK) and it is then using KNI to pass data plane packets 
(say IPSec packets) to DPDK application. So will it effect the fast path 
performance in this scenario?

Thanks,
Deepak
On Wed, Jan 14, 2015 at 1:32 PM, Zhang, Helin mailto:helin.zhang at intel.com>> wrote:
Hi Deepak

Exception path or KNI just provide an exceptional path for packet exchanging 
between user space and kernel space. All packet IO are still in user space 
DPDK, Linux kernel still doesn?t know the NIC port. So, no standard Linux 
interrupt.

Regards,
Helin

From: Deepak Sehrawat [mailto:d.sehrawat at 
gmail.com]
Sent: Wednesday, January 14, 2015 3:58 PM
To: Zhang, Helin
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Fast Path Query


Hi Helin,

If we use exception_path or KNI, which extracts packet from Linux kernel (for 
DPDK application processing), will it still remain fast path? Will it not 
impact the performance; as Linux interrupt framework shall also come into 
picture here?


On Wed, Jan 14, 2015 at 1:17 PM, Zhang, Helin mailto:helin.zhang at intel.com>> wrote:
Hi Deepak

If a NIC port is controlled by DPDK, all packets received by that port will go 
directly to DPDK, and Linux kernel doesn't know those packets anymore.
But, the packets received by DPDK can be put into kernel by two special ways. 
They are exception_path and KNI. Please check the examples/ for more details.
In the future, a port may be co-controlled by both Linux and DPDK. Part of 
queues will be controlled by Linux kernel driver, part of queues will be 
controlled by DPDK. Check the DPDK roadmap for more details.

Regards,
Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On 
> Behalf Of Deepak Sehrawat
> Sent: Wednesday, January 14, 2015 2:16 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Fast Path Query
>
> Hi All,
>
> I have a use-case where my slow path application (control path) is to run on
> Linux where as my data path is to run as DPDK application. Because both
> control and data packets are going to be received via same NIC card, how will
> these two flows be separated and passed on to Linux control app and DPDK
> data path app respectively? In short I want to understand how NIC received
> packets are separated between Linux Eth driver and PMD (poll mode
> driver) of DPDK?
>
> Thanks for the help in advance.
>
> Thanks,
> Deepak

[dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network Connection' NIC cards

[Zhang, Helin]

Check the device ID can know if your NIC is supported by dpdk or not.

"Lspci -nn | grep Eth" will show like below, 1521 is the device ID.
04:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
Connection [8086:1521]
Then check rte_pci_dev_ids.h to see if that device ID is listed in that file or 
not, then you know if your NIC is supported or not.

Regards,
Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ayon jyoti Biswas
> Sent: Thursday, January 15, 2015 2:29 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] How to run intel dpdk apps on '82574L Gigabit Network
> Connection' NIC cards
> 
> hi,
> i have two* '82574L Gigabit Network Connection'*  NIC cards .
> Can i run dpdk application with this interfaces .
> i have binded to igb_uio . My l2forward application is successfully getting
> initialized but could not receive/transmit traffic .
> How can i run dpdk l2fwd application with this NIC cards .
> 
> 
> 
> ./build/app/l2fwd -c 0x3 -n 2 -m 512 -- -p 0x3
> 
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7f8bbaa0 (size = 0x20)
> EAL: Ask a virtual area of 0xffc0 bytes
> EAL: Virtual area found at 0x7f8abac0 (size = 0xffc0)
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7f8aba80 (size = 0x20)
> EAL: Requesting 256 pages of size 2MB from socket 0
> EAL: TSC frequency is ~3192736 KHz
> EAL: Master core 0 is ready (tid=bb5be800)
> EAL: Core 1 is ready (tid=b9ffe700)
> EAL: PCI device :02:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10d3 rte_em_pmd
> EAL:   PCI memory mapped at 0x7f8bb95de000
> EAL:   PCI memory mapped at 0x7f8bb955e000
> EAL:   PCI memory mapped at 0x7f8bb955a000
> EAL: PCI device :03:00.0 on NUMA socket -1
> EAL:   probe driver: 8086:10d3 rte_em_pmd
> EAL:   PCI memory mapped at 0x7f8bb953a000
> EAL:   PCI memory mapped at 0x7f8bb94ba000
> EAL:   PCI memory mapped at 0x7f8bb94b6000
> 
> NUMBER OF PORTS=2**
> Lcore 0: RX port 0
> Lcore 1: RX port 1
> Initializing port 0...
>  ***PORTID= 0*
> 
> 
> ./tools/pci_unbind.py --status
> 
> Network devices using IGB_UIO driver
> 
> :02:00.0 '82574L Gigabit Network Connection' drv=igb_uio
> unused=e1000e
> :03:00.0 '82574L Gigabit Network Connection' drv=igb_uio
> unused=e1000e
> 
> 
> ethtool -i eth3
> driver: e1000e
> version: 2.1.4-k
> firmware-version: 1.8-0
> bus-info: :03:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
> 
> ethtool -i eth4
> driver: e1000e
> version: 2.1.4-k
> firmware-version: 1.8-0
> bus-info: :02:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
> 
> 
> thanks
> ayon

[dpdk-dev] Why nothing since 1.8.0?

[Ouyang, Changchun]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> Sent: Thursday, January 15, 2015 12:15 PM
> To: Neil Horman; Stephen Hemminger
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Why nothing since 1.8.0?
> 
> +1, Some patch set might be ready for being merged.
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Thursday, January 15, 2015 5:02 AM
> > To: Stephen Hemminger
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] Why nothing since 1.8.0?
> >
> > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger wrote:
> > > Ok, so 1.8.0 came out almost a month ago and none of the patches
> > > that were deferred waiting for the release got merged since then.
> > > Last commit in git is the 1.8.0 release.
> > >
> > > Where is the post-merge window bundle, where are the later commits?
> > > Lots of patches are sitting rotting in patchwork...
> > >
> > >
> >
> > +1, I've had the same questions.
> > Neil

+1,  the earlier some patches are merged into mainline, and the easier those 
sequent patch sets can resolve their conflicts.
Thanks
Changchun

[dpdk-dev] Why nothing since 1.8.0?

[Zhang, Helin]

+1, Some patch set might be ready for being merged.

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Thursday, January 15, 2015 5:02 AM
> To: Stephen Hemminger
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Why nothing since 1.8.0?
> 
> On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger wrote:
> > Ok, so 1.8.0 came out almost a month ago and none of the patches that
> > were deferred waiting for the release got merged since then.
> > Last commit in git is the 1.8.0 release.
> >
> > Where is the post-merge window bundle, where are the later commits?
> > Lots of patches are sitting rotting in patchwork...
> >
> >
> 
> +1, I've had the same questions.
> Neil