[PATCH 0/3] fm10k: enable FTAG based forwarding

[PATCH 0/3] fm10k: enable FTAG based forwarding

[Wang Xiao W]

This patch set adds support for FTAG based forwarding in fm10k. This feature
is a particularity of fm10k, so I add an introduction for it in fm10k.rst.
A FTAG unit test is kept internally for feature testing, it's not included
in the patch set due to the particularity.

Wang Xiao W (3):
  fm10k: enable FTAG based forwarding
  doc: add introduction for fm10k FTAG based forwarding
  doc: update release note for fm10k FTAG support

 config/common_bsdapp                 |  1 +
 config/common_linuxapp               |  1 +
 doc/guides/nics/fm10k.rst            | 15 ++++++++++++++-
 doc/guides/rel_notes/release_2_3.rst |  1 +
 drivers/net/fm10k/fm10k_ethdev.c     |  8 ++++++++
 drivers/net/fm10k/fm10k_rxtx.c       | 17 +++++++++++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c   |  9 +++++++++
 7 files changed, 51 insertions(+), 1 deletion(-)

-- 
1.9.3

[PATCH 1/3] fm10k: enable FTAG based forwarding

[Wang Xiao W]

This patch enables reading sglort info into mbuf for RX and inserting
an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
selected from rte_mbuf structure for sglort is not used in fm10k now.
In FTAG based forwarding mode, the switch will forward packets according
to glort info in FTAG rather than mac and vlan table.

To activate this feature, user needs to turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
to y in common_linuxapp or common_bsdapp. Currently this feature is supported
only on PF, because FM10K_PFVTCTL register is read-only for VF.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 config/common_bsdapp               |  1 +
 config/common_linuxapp             |  1 +
 drivers/net/fm10k/fm10k_ethdev.c   |  8 ++++++++
 drivers/net/fm10k/fm10k_rxtx.c     | 17 +++++++++++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c |  9 +++++++++
 5 files changed, 36 insertions(+)

diff --git a/config/common_bsdapp b/config/common_bsdapp
index ed7c31c..451f81a 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
 CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
+CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
 
 #
 # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 74bc515..c928bce 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
 CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
 CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
+CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
 
 #
 # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index e4aed94..cc8317f 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -668,6 +668,14 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
 			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
 			return -1;
 		}
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
+		 * register is read-only for VF.
+		 */
+		if (hw->mac.type == fm10k_mac_pf)
+			FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
+					FM10K_PFVTCTL_FTAG_DESC_ENABLE);
+#endif
 
 		/* set location and size for descriptor ring */
 		FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index e958865..f87987d 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -152,6 +152,13 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
 		mbuf->vlan_tci = desc.w.vlan;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		mbuf->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
+#endif
 
 		rx_pkts[count] = mbuf;
 		if (++next_dd == q->nb_desc) {
@@ -307,6 +314,13 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
 		first_seg->vlan_tci = desc.w.vlan;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		first_seg->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
+#endif
 
 		/* Prefetch data of first segment, if configured to do so. */
 		rte_packet_prefetch((char *)first_seg->buf_addr +
@@ -432,6 +446,9 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, struct rte_mbuf *mb)
 	q->nb_free -= mb->nb_segs;
 
 	q->hw_ring[q->next_free].flags = 0;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+	q->hw_ring[q->next_free].flags |= FM10K_TXD_FLAG_FTAG;
+#endif
 	/* set checksum flags on first descriptor of packet. SCTP checksum
 	 * offload is not supported, but we do not explicitly check for this
 	 * case in favor of greatly simplified processing. */
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 2a57eef..0b0f2e3 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -198,7 +198,12 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
 	    rxmode->header_split == 1)
 		return -1;
 
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+	return -1;
+#else
 	return 0;
+#endif
+
 #else
 	RTE_SET_USED(dev);
 	return -1;
@@ -648,7 +653,11 @@ fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)
 	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) != FM10K_SIMPLE_TX_FLAG)
 		return -1;
 
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+	return -1;
+#else
 	return 0;
+#endif
 }
 
 static inline void
-- 
1.9.3

Re: [PATCH 1/3] fm10k: enable FTAG based forwarding

[Qiu, Michael]

On 1/25/2016 4:08 PM, Wang Xiao W wrote:
> This patch enables reading sglort info into mbuf for RX and inserting
> an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> selected from rte_mbuf structure for sglort is not used in fm10k now.
> In FTAG based forwarding mode, the switch will forward packets according
> to glort info in FTAG rather than mac and vlan table.
>
> To activate this feature, user needs to turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> to y in common_linuxapp or common_bsdapp. Currently this feature is supported
> only on PF, because FM10K_PFVTCTL register is read-only for VF.
>
> Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> ---
>  config/common_bsdapp               |  1 +
>  config/common_linuxapp             |  1 +
>  drivers/net/fm10k/fm10k_ethdev.c   |  8 ++++++++
>  drivers/net/fm10k/fm10k_rxtx.c     | 17 +++++++++++++++++
>  drivers/net/fm10k/fm10k_rxtx_vec.c |  9 +++++++++
>  5 files changed, 36 insertions(+)
>
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index ed7c31c..451f81a 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
>  CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
>  
>  #
>  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 74bc515..c928bce 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
>  CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
> +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
>  
>  #
>  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
> index e4aed94..cc8317f 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -668,6 +668,14 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
>  			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
>  			return -1;
>  		}
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
> +		 * register is read-only for VF.
> +		 */
> +		if (hw->mac.type == fm10k_mac_pf)
> +			FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
> +					FM10K_PFVTCTL_FTAG_DESC_ENABLE);

So here if somebody enable FTAG, when compile, but he use VF, what will
happen? We'd better to give a error message when he try to use VF with FTAG.

Thanks,
Michael
> +#endif
>  
>  		/* set location and size for descriptor ring */
>  		FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
> diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
> index e958865..f87987d 100644
> --- a/drivers/net/fm10k/fm10k_rxtx.c
> +++ b/drivers/net/fm10k/fm10k_rxtx.c
> @@ -152,6 +152,13 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
>  		 */
>  		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
>  		mbuf->vlan_tci = desc.w.vlan;
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +		/**
> +		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
> +		 * so it can be selected to store sglort value.
> +		 */
> +		mbuf->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
> +#endif
>  
>  		rx_pkts[count] = mbuf;
>  		if (++next_dd == q->nb_desc) {
> @@ -307,6 +314,13 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
>  		 */
>  		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
>  		first_seg->vlan_tci = desc.w.vlan;
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +		/**
> +		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
> +		 * so it can be selected to store sglort value.
> +		 */
> +		first_seg->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
> +#endif
>  
>  		/* Prefetch data of first segment, if configured to do so. */
>  		rte_packet_prefetch((char *)first_seg->buf_addr +
> @@ -432,6 +446,9 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, struct rte_mbuf *mb)
>  	q->nb_free -= mb->nb_segs;
>  
>  	q->hw_ring[q->next_free].flags = 0;
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +	q->hw_ring[q->next_free].flags |= FM10K_TXD_FLAG_FTAG;
> +#endif
>  	/* set checksum flags on first descriptor of packet. SCTP checksum
>  	 * offload is not supported, but we do not explicitly check for this
>  	 * case in favor of greatly simplified processing. */
> diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c b/drivers/net/fm10k/fm10k_rxtx_vec.c
> index 2a57eef..0b0f2e3 100644
> --- a/drivers/net/fm10k/fm10k_rxtx_vec.c
> +++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
> @@ -198,7 +198,12 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
>  	    rxmode->header_split == 1)
>  		return -1;
>  
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +	return -1;
> +#else
>  	return 0;
> +#endif
> +
>  #else
>  	RTE_SET_USED(dev);
>  	return -1;
> @@ -648,7 +653,11 @@ fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)
>  	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) != FM10K_SIMPLE_TX_FLAG)
>  		return -1;
>  
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +	return -1;
> +#else
>  	return 0;
> +#endif
>  }
>  
>  static inline void

Re: [PATCH 1/3] fm10k: enable FTAG based forwarding

[Wang, Xiao W]

> -----Original Message-----
> From: Qiu, Michael
> Sent: Tuesday, February 2, 2016 11:07 AM
> To: Wang, Xiao W <xiao.w.wang@intel.com>; Chen, Jing D
> <jing.d.chen@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/3] fm10k: enable FTAG based forwarding
> 
> On 1/25/2016 4:08 PM, Wang Xiao W wrote:
> > This patch enables reading sglort info into mbuf for RX and inserting
> > an FTAG at the beginning of the packet for TX. The vlan_tci_outer
> > field selected from rte_mbuf structure for sglort is not used in fm10k now.
> > In FTAG based forwarding mode, the switch will forward packets
> > according to glort info in FTAG rather than mac and vlan table.
> >
> > To activate this feature, user needs to turn
> > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > to y in common_linuxapp or common_bsdapp. Currently this feature is
> > supported only on PF, because FM10K_PFVTCTL register is read-only for VF.
> >
> > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> > ---
> >  config/common_bsdapp               |  1 +
> >  config/common_linuxapp             |  1 +
> >  drivers/net/fm10k/fm10k_ethdev.c   |  8 ++++++++
> >  drivers/net/fm10k/fm10k_rxtx.c     | 17 +++++++++++++++++
> >  drivers/net/fm10k/fm10k_rxtx_vec.c |  9 +++++++++
> >  5 files changed, 36 insertions(+)
> >
> > diff --git a/config/common_bsdapp b/config/common_bsdapp index
> > ed7c31c..451f81a 100644
> > --- a/config/common_bsdapp
> > +++ b/config/common_bsdapp
> > @@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
> >  CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> >  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> >  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> > +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
> >
> >  #
> >  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD diff --git
> > a/config/common_linuxapp b/config/common_linuxapp index
> > 74bc515..c928bce 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> >  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> >  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> >  CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
> > +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
> >
> >  #
> >  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD diff --git
> > a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
> > index e4aed94..cc8317f 100644
> > --- a/drivers/net/fm10k/fm10k_ethdev.c
> > +++ b/drivers/net/fm10k/fm10k_ethdev.c
> > @@ -668,6 +668,14 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
> >  			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
> >  			return -1;
> >  		}
> > +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> > +		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
> > +		 * register is read-only for VF.
> > +		 */
> > +		if (hw->mac.type == fm10k_mac_pf)
> > +			FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
> > +
> 	FM10K_PFVTCTL_FTAG_DESC_ENABLE);
> 
> So here if somebody enable FTAG, when compile, but he use VF, what will
> happen? We'd better to give a error message when he try to use VF with FTAG.
> 
> Thanks,
> Michael

Yes, we'd better to give an error message and return failure in this use case, I'll
rework the patch. Thanks for your comment. 

Best Regards,
Wang, Xiao W

[PATCH v2 0/3] fm10k: enable FTAG based forwarding

[Wang Xiao W]

v2:
* Gave an error message for VF FTAG use case.

* Added a notice in the doc to emphasize that application should ensure
  an appropriate FTAG for every frame in FTAG based forwarding mode.

Wang Xiao W (3):
  fm10k: enable FTAG based forwarding
  doc: add introduction for fm10k FTAG based forwarding
  doc: update release note for fm10k FTAG support

 config/common_bsdapp                 |  1 +
 config/common_linuxapp               |  1 +
 doc/guides/nics/fm10k.rst            | 16 +++++++++++++++-
 doc/guides/rel_notes/release_2_3.rst |  1 +
 drivers/net/fm10k/fm10k_ethdev.c     | 12 ++++++++++++
 drivers/net/fm10k/fm10k_rxtx.c       | 17 +++++++++++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c   |  9 +++++++++
 7 files changed, 56 insertions(+), 1 deletion(-)

-- 
1.9.3

[PATCH v2 1/3] fm10k: enable FTAG based forwarding

[Wang Xiao W]

This patch enables reading sglort info into mbuf for RX and inserting
an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
selected from rte_mbuf structure for sglort is not used in fm10k now.
In FTAG based forwarding mode, the switch will forward packets according
to glort info in FTAG rather than mac and vlan table.

To activate this feature, user needs to turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
to y in common_linuxapp or common_bsdapp. Currently this feature is supported
only on PF, because FM10K_PFVTCTL register is read-only for VF.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 config/common_bsdapp               |  1 +
 config/common_linuxapp             |  1 +
 drivers/net/fm10k/fm10k_ethdev.c   | 12 ++++++++++++
 drivers/net/fm10k/fm10k_rxtx.c     | 17 +++++++++++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c |  9 +++++++++
 5 files changed, 40 insertions(+)

diff --git a/config/common_bsdapp b/config/common_bsdapp
index ed7c31c..451f81a 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
 CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
+CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
 
 #
 # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 74bc515..c928bce 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
 CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
 CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
+CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
 
 #
 # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index e4aed94..3a15c24 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -668,6 +668,18 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
 			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
 			return -1;
 		}
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
+		 * register is read-only for VF.
+		 */
+		if (hw->mac.type == fm10k_mac_pf)
+			FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
+					FM10K_PFVTCTL_FTAG_DESC_ENABLE);
+		else {
+			PMD_INIT_LOG(ERR, "FTAG is not supported in VF.\n");
+			return -1;
+		}
+#endif
 
 		/* set location and size for descriptor ring */
 		FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index e958865..f87987d 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -152,6 +152,13 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
 		mbuf->vlan_tci = desc.w.vlan;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		mbuf->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
+#endif
 
 		rx_pkts[count] = mbuf;
 		if (++next_dd == q->nb_desc) {
@@ -307,6 +314,13 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
 		first_seg->vlan_tci = desc.w.vlan;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		first_seg->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
+#endif
 
 		/* Prefetch data of first segment, if configured to do so. */
 		rte_packet_prefetch((char *)first_seg->buf_addr +
@@ -432,6 +446,9 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, struct rte_mbuf *mb)
 	q->nb_free -= mb->nb_segs;
 
 	q->hw_ring[q->next_free].flags = 0;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+	q->hw_ring[q->next_free].flags |= FM10K_TXD_FLAG_FTAG;
+#endif
 	/* set checksum flags on first descriptor of packet. SCTP checksum
 	 * offload is not supported, but we do not explicitly check for this
 	 * case in favor of greatly simplified processing. */
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 2a57eef..0b0f2e3 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -198,7 +198,12 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
 	    rxmode->header_split == 1)
 		return -1;
 
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+	return -1;
+#else
 	return 0;
+#endif
+
 #else
 	RTE_SET_USED(dev);
 	return -1;
@@ -648,7 +653,11 @@ fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)
 	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) != FM10K_SIMPLE_TX_FLAG)
 		return -1;
 
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+	return -1;
+#else
 	return 0;
+#endif
 }
 
 static inline void
-- 
1.9.3

Re: [PATCH v2 1/3] fm10k: enable FTAG based forwarding

[Chen, Jing D]

Hi,

Best Regards,
Mark


> -----Original Message-----
> From: Wang, Xiao W
> Sent: Tuesday, February 02, 2016 6:50 PM
> To: Chen, Jing D
> Cc: dev@dpdk.org; Qiu, Michael; He, Shaopeng; Wang, Xiao W
> Subject: [PATCH v2 1/3] fm10k: enable FTAG based forwarding
> 
> This patch enables reading sglort info into mbuf for RX and inserting
> an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> selected from rte_mbuf structure for sglort is not used in fm10k now.
> In FTAG based forwarding mode, the switch will forward packets according
> to glort info in FTAG rather than mac and vlan table.
> 
> To activate this feature, user needs to turn
> ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> to y in common_linuxapp or common_bsdapp. Currently this feature is
> supported
> only on PF, because FM10K_PFVTCTL register is read-only for VF.
> 
> Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> ---
>  config/common_bsdapp               |  1 +
>  config/common_linuxapp             |  1 +
>  drivers/net/fm10k/fm10k_ethdev.c   | 12 ++++++++++++
>  drivers/net/fm10k/fm10k_rxtx.c     | 17 +++++++++++++++++
>  drivers/net/fm10k/fm10k_rxtx_vec.c |  9 +++++++++
>  5 files changed, 40 insertions(+)
> 
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index ed7c31c..451f81a 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
>  CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
> 
>  #
>  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 74bc515..c928bce 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
>  CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
> +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
> 
>  #
>  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> b/drivers/net/fm10k/fm10k_ethdev.c
> index e4aed94..3a15c24 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -668,6 +668,18 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
>  			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
>  			return -1;
>  		}
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
> +		 * register is read-only for VF.
> +		 */
> +		if (hw->mac.type == fm10k_mac_pf)
> +			FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
> +
> 	FM10K_PFVTCTL_FTAG_DESC_ENABLE);
> +		else {
> +			PMD_INIT_LOG(ERR, "FTAG is not supported in
> VF.\n");

"\n" is not necessary.

> +			return -1;

Return "-ENOTSUP"?

> +		}
> +#endif
> 
>  		/* set location and size for descriptor ring */
>  		FM10K_WRITE_REG(hw, FM10K_TDBAL(i),

Re: [PATCH v2 1/3] fm10k: enable FTAG based forwarding

[Wang, Xiao W]

Hi Mark,

> -----Original Message-----
> From: Chen, Jing D
> Sent: Wednesday, February 3, 2016 2:53 PM
> To: Wang, Xiao W <xiao.w.wang@intel.com>
> Cc: dev@dpdk.org; Qiu, Michael <michael.qiu@intel.com>; He, Shaopeng
> <shaopeng.he@intel.com>
> Subject: RE: [PATCH v2 1/3] fm10k: enable FTAG based forwarding
> 
> Hi,
> 
> Best Regards,
> Mark
> 
> 
> > -----Original Message-----
> > From: Wang, Xiao W
> > Sent: Tuesday, February 02, 2016 6:50 PM
> > To: Chen, Jing D
> > Cc: dev@dpdk.org; Qiu, Michael; He, Shaopeng; Wang, Xiao W
> > Subject: [PATCH v2 1/3] fm10k: enable FTAG based forwarding
> >
> > This patch enables reading sglort info into mbuf for RX and inserting
> > an FTAG at the beginning of the packet for TX. The vlan_tci_outer
> > field selected from rte_mbuf structure for sglort is not used in fm10k now.
> > In FTAG based forwarding mode, the switch will forward packets
> > according to glort info in FTAG rather than mac and vlan table.
> >
> > To activate this feature, user needs to turn
> > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > to y in common_linuxapp or common_bsdapp. Currently this feature is
> > supported only on PF, because FM10K_PFVTCTL register is read-only for
> > VF.
> >
> > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> > ---
> >  config/common_bsdapp               |  1 +
> >  config/common_linuxapp             |  1 +
> >  drivers/net/fm10k/fm10k_ethdev.c   | 12 ++++++++++++
> >  drivers/net/fm10k/fm10k_rxtx.c     | 17 +++++++++++++++++
> >  drivers/net/fm10k/fm10k_rxtx_vec.c |  9 +++++++++
> >  5 files changed, 40 insertions(+)
> >
> > diff --git a/config/common_bsdapp b/config/common_bsdapp index
> > ed7c31c..451f81a 100644
> > --- a/config/common_bsdapp
> > +++ b/config/common_bsdapp
> > @@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
> >  CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> >  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> >  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> > +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
> >
> >  #
> >  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD diff --git
> > a/config/common_linuxapp b/config/common_linuxapp index
> > 74bc515..c928bce 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> >  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> >  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> >  CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
> > +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
> >
> >  #
> >  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD diff --git
> > a/drivers/net/fm10k/fm10k_ethdev.c
> > b/drivers/net/fm10k/fm10k_ethdev.c
> > index e4aed94..3a15c24 100644
> > --- a/drivers/net/fm10k/fm10k_ethdev.c
> > +++ b/drivers/net/fm10k/fm10k_ethdev.c
> > @@ -668,6 +668,18 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
> >  			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
> >  			return -1;
> >  		}
> > +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> > +		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
> > +		 * register is read-only for VF.
> > +		 */
> > +		if (hw->mac.type == fm10k_mac_pf)
> > +			FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
> > +
> > 	FM10K_PFVTCTL_FTAG_DESC_ENABLE);
> > +		else {
> > +			PMD_INIT_LOG(ERR, "FTAG is not supported in
> > VF.\n");
> 
> "\n" is not necessary.

Yes, PMD_INIT_LOG has already included a "\n". I will remove it.

> 
> > +			return -1;
> 
> Return "-ENOTSUP"?
> 

Yes, "-ENOTSUP" is meaningful, thanks for your comments, I'll fix it in v3.

Best Regards,
Wang Xiao

> > +		}
> > +#endif
> >
> >  		/* set location and size for descriptor ring */
> >  		FM10K_WRITE_REG(hw, FM10K_TDBAL(i),

[PATCH v3 0/3] fm10k: enable FTAG based forwarding

[Wang Xiao W]

v3:
* Removed "\n" in PMD_INIT_LOG.

* Returned "-ENOTSUP" instead of -1 in VF FTAG use case.

v2:
* Gave an error message for VF FTAG use case.

* Added a notice in the doc to emphasize that application should ensure
  an appropriate FTAG for every frame in FTAG based forwarding mode.

Wang Xiao W (3):
  fm10k: enable FTAG based forwarding
  doc: add introduction for fm10k FTAG based forwarding
  doc: update release note for fm10k FTAG support

 config/common_bsdapp                 |  1 +
 config/common_linuxapp               |  1 +
 doc/guides/nics/fm10k.rst            | 16 +++++++++++++++-
 doc/guides/rel_notes/release_2_3.rst |  1 +
 drivers/net/fm10k/fm10k_ethdev.c     | 12 ++++++++++++
 drivers/net/fm10k/fm10k_rxtx.c       | 17 +++++++++++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c   |  9 +++++++++
 7 files changed, 56 insertions(+), 1 deletion(-)

-- 
1.9.3

[PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Wang Xiao W]

This patch enables reading sglort info into mbuf for RX and inserting
an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
selected from rte_mbuf structure for sglort is not used in fm10k now.
In FTAG based forwarding mode, the switch will forward packets according
to glort info in FTAG rather than mac and vlan table.

To activate this feature, user needs to turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
to y in common_linuxapp or common_bsdapp. Currently this feature is supported
only on PF, because FM10K_PFVTCTL register is read-only for VF.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 config/common_bsdapp               |  1 +
 config/common_linuxapp             |  1 +
 drivers/net/fm10k/fm10k_ethdev.c   | 12 ++++++++++++
 drivers/net/fm10k/fm10k_rxtx.c     | 17 +++++++++++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c |  9 +++++++++
 5 files changed, 40 insertions(+)

diff --git a/config/common_bsdapp b/config/common_bsdapp
index ed7c31c..451f81a 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
 CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
+CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
 
 #
 # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 74bc515..c928bce 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
 CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
 CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
+CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
 
 #
 # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index e4aed94..65d355e 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -668,6 +668,18 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
 			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
 			return -1;
 		}
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
+		 * register is read-only for VF.
+		 */
+		if (hw->mac.type == fm10k_mac_pf)
+			FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
+					FM10K_PFVTCTL_FTAG_DESC_ENABLE);
+		else {
+			PMD_INIT_LOG(ERR, "FTAG is not supported in VF.");
+			return -ENOTSUP;
+		}
+#endif
 
 		/* set location and size for descriptor ring */
 		FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index e958865..f87987d 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -152,6 +152,13 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
 		mbuf->vlan_tci = desc.w.vlan;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		mbuf->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
+#endif
 
 		rx_pkts[count] = mbuf;
 		if (++next_dd == q->nb_desc) {
@@ -307,6 +314,13 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
 		first_seg->vlan_tci = desc.w.vlan;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		first_seg->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
+#endif
 
 		/* Prefetch data of first segment, if configured to do so. */
 		rte_packet_prefetch((char *)first_seg->buf_addr +
@@ -432,6 +446,9 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, struct rte_mbuf *mb)
 	q->nb_free -= mb->nb_segs;
 
 	q->hw_ring[q->next_free].flags = 0;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+	q->hw_ring[q->next_free].flags |= FM10K_TXD_FLAG_FTAG;
+#endif
 	/* set checksum flags on first descriptor of packet. SCTP checksum
 	 * offload is not supported, but we do not explicitly check for this
 	 * case in favor of greatly simplified processing. */
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 2a57eef..0b0f2e3 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -198,7 +198,12 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
 	    rxmode->header_split == 1)
 		return -1;
 
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+	return -1;
+#else
 	return 0;
+#endif
+
 #else
 	RTE_SET_USED(dev);
 	return -1;
@@ -648,7 +653,11 @@ fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)
 	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) != FM10K_SIMPLE_TX_FLAG)
 		return -1;
 
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+	return -1;
+#else
 	return 0;
+#endif
 }
 
 static inline void
-- 
1.9.3

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Bruce Richardson]

On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote:
> This patch enables reading sglort info into mbuf for RX and inserting
> an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> selected from rte_mbuf structure for sglort is not used in fm10k now.
> In FTAG based forwarding mode, the switch will forward packets according
> to glort info in FTAG rather than mac and vlan table.
> 
> To activate this feature, user needs to turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> to y in common_linuxapp or common_bsdapp. Currently this feature is supported
> only on PF, because FM10K_PFVTCTL register is read-only for VF.
> 
> Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>

Any comments on this patch?

My thoughts: is there a way in which this could be done without adding in a new
build time config option?

/Bruce

> ---
>  config/common_bsdapp               |  1 +
>  config/common_linuxapp             |  1 +
>  drivers/net/fm10k/fm10k_ethdev.c   | 12 ++++++++++++
>  drivers/net/fm10k/fm10k_rxtx.c     | 17 +++++++++++++++++
>  drivers/net/fm10k/fm10k_rxtx_vec.c |  9 +++++++++
>  5 files changed, 40 insertions(+)
> 
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index ed7c31c..451f81a 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
>  CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
>  
>  #
>  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 74bc515..c928bce 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
>  CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
>  CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
>  CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
> +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
>  
>  #
>  # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
> index e4aed94..65d355e 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -668,6 +668,18 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
>  			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
>  			return -1;
>  		}
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
> +		 * register is read-only for VF.
> +		 */
> +		if (hw->mac.type == fm10k_mac_pf)
> +			FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
> +					FM10K_PFVTCTL_FTAG_DESC_ENABLE);
> +		else {
> +			PMD_INIT_LOG(ERR, "FTAG is not supported in VF.");
> +			return -ENOTSUP;
> +		}
> +#endif
>  
>  		/* set location and size for descriptor ring */
>  		FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
> diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
> index e958865..f87987d 100644
> --- a/drivers/net/fm10k/fm10k_rxtx.c
> +++ b/drivers/net/fm10k/fm10k_rxtx.c
> @@ -152,6 +152,13 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
>  		 */
>  		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
>  		mbuf->vlan_tci = desc.w.vlan;
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +		/**
> +		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
> +		 * so it can be selected to store sglort value.
> +		 */
> +		mbuf->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
> +#endif
>  
>  		rx_pkts[count] = mbuf;
>  		if (++next_dd == q->nb_desc) {
> @@ -307,6 +314,13 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
>  		 */
>  		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
>  		first_seg->vlan_tci = desc.w.vlan;
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +		/**
> +		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
> +		 * so it can be selected to store sglort value.
> +		 */
> +		first_seg->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
> +#endif
>  
>  		/* Prefetch data of first segment, if configured to do so. */
>  		rte_packet_prefetch((char *)first_seg->buf_addr +
> @@ -432,6 +446,9 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, struct rte_mbuf *mb)
>  	q->nb_free -= mb->nb_segs;
>  
>  	q->hw_ring[q->next_free].flags = 0;
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +	q->hw_ring[q->next_free].flags |= FM10K_TXD_FLAG_FTAG;
> +#endif
>  	/* set checksum flags on first descriptor of packet. SCTP checksum
>  	 * offload is not supported, but we do not explicitly check for this
>  	 * case in favor of greatly simplified processing. */
> diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c b/drivers/net/fm10k/fm10k_rxtx_vec.c
> index 2a57eef..0b0f2e3 100644
> --- a/drivers/net/fm10k/fm10k_rxtx_vec.c
> +++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
> @@ -198,7 +198,12 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
>  	    rxmode->header_split == 1)
>  		return -1;
>  
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +	return -1;
> +#else
>  	return 0;
> +#endif
> +
>  #else
>  	RTE_SET_USED(dev);
>  	return -1;
> @@ -648,7 +653,11 @@ fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)
>  	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) != FM10K_SIMPLE_TX_FLAG)
>  		return -1;
>  
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> +	return -1;
> +#else
>  	return 0;
> +#endif
>  }
>  
>  static inline void
> -- 
> 1.9.3
> 

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Thomas Monjalon]

2016-02-24 15:42, Bruce Richardson:
> On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote:
> > This patch enables reading sglort info into mbuf for RX and inserting
> > an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> > selected from rte_mbuf structure for sglort is not used in fm10k now.
> > In FTAG based forwarding mode, the switch will forward packets according
> > to glort info in FTAG rather than mac and vlan table.
> > 
> > To activate this feature, user needs to turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > to y in common_linuxapp or common_bsdapp. Currently this feature is supported
> > only on PF, because FM10K_PFVTCTL register is read-only for VF.
> > 
> > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> 
> Any comments on this patch?
> 
> My thoughts: is there a way in which this could be done without adding in a new
> build time config option?

Bruce, it's simpler to explain that build time options are forbidden to
enable such options.
Or the terrific kid's approach: one day, the Big Build-Option Eater will come
and will eat every undecided features! ;)

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Bruce Richardson]

On Wed, Feb 24, 2016 at 05:37:45PM +0100, Thomas Monjalon wrote:
> 2016-02-24 15:42, Bruce Richardson:
> > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote:
> > > This patch enables reading sglort info into mbuf for RX and inserting
> > > an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> > > selected from rte_mbuf structure for sglort is not used in fm10k now.
> > > In FTAG based forwarding mode, the switch will forward packets according
> > > to glort info in FTAG rather than mac and vlan table.
> > > 
> > > To activate this feature, user needs to turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > > to y in common_linuxapp or common_bsdapp. Currently this feature is supported
> > > only on PF, because FM10K_PFVTCTL register is read-only for VF.
> > > 
> > > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> > 
> > Any comments on this patch?
> > 
> > My thoughts: is there a way in which this could be done without adding in a new
> > build time config option?
> 
> Bruce, it's simpler to explain that build time options are forbidden to
> enable such options.
> Or the terrific kid's approach: one day, the Big Build-Option Eater will come
> and will eat every undecided features! ;)

Good-cop, bad-cop, guess who I'm playing? :-)

/Bruce

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Chen, Jing D]

Hi, Bruce, Thomas,

Best Regards,
Mark

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, February 25, 2016 12:38 AM
> To: Richardson, Bruce; Wang, Xiao W
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based
> forwarding
> 
> 2016-02-24 15:42, Bruce Richardson:
> > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote:
> > > This patch enables reading sglort info into mbuf for RX and inserting
> > > an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> > > selected from rte_mbuf structure for sglort is not used in fm10k now.
> > > In FTAG based forwarding mode, the switch will forward packets
> according
> > > to glort info in FTAG rather than mac and vlan table.
> > >
> > > To activate this feature, user needs to turn
> ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > > to y in common_linuxapp or common_bsdapp. Currently this feature is
> supported
> > > only on PF, because FM10K_PFVTCTL register is read-only for VF.
> > >
> > > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> >
> > Any comments on this patch?
> >
> > My thoughts: is there a way in which this could be done without adding in a
> new
> > build time config option?
> 
> Bruce, it's simpler to explain that build time options are forbidden to
> enable such options.
> Or the terrific kid's approach: one day, the Big Build-Option Eater will come
> and will eat every undecided features! ;)

This feature is trying to use FTAG (a unique tech in fm10k) instead of mac/vlan
to forward packets. App need a way to tell PMD driver that which forwarding
style it would like to use. 
So, the best option is to let packets carry a flag in mbuf to tell drive in fast path. 
You can see that this is unique to fm10k and we thought community won't like to see 
this flag introduced into mbuf. If you do agree, we can introduce a new flag.
So, we step backwards and assume customer will use static configurations to enable
this feature. After it is enabled, we'll assume app will use FTAG for all packets.

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Bruce Richardson]

On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> Hi, Bruce, Thomas,
> 
> Best Regards,
> Mark
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Thursday, February 25, 2016 12:38 AM
> > To: Richardson, Bruce; Wang, Xiao W
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based
> > forwarding
> > 
> > 2016-02-24 15:42, Bruce Richardson:
> > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote:
> > > > This patch enables reading sglort info into mbuf for RX and inserting
> > > > an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> > > > selected from rte_mbuf structure for sglort is not used in fm10k now.
> > > > In FTAG based forwarding mode, the switch will forward packets
> > according
> > > > to glort info in FTAG rather than mac and vlan table.
> > > >
> > > > To activate this feature, user needs to turn
> > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > > > to y in common_linuxapp or common_bsdapp. Currently this feature is
> > supported
> > > > only on PF, because FM10K_PFVTCTL register is read-only for VF.
> > > >
> > > > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> > >
> > > Any comments on this patch?
> > >
> > > My thoughts: is there a way in which this could be done without adding in a
> > new
> > > build time config option?
> > 
> > Bruce, it's simpler to explain that build time options are forbidden to
> > enable such options.
> > Or the terrific kid's approach: one day, the Big Build-Option Eater will come
> > and will eat every undecided features! ;)
> 
> This feature is trying to use FTAG (a unique tech in fm10k) instead of mac/vlan
> to forward packets. App need a way to tell PMD driver that which forwarding
> style it would like to use. 

Why not just specify this in the port configuration at setup time?

> So, the best option is to let packets carry a flag in mbuf to tell drive in fast path. 
> You can see that this is unique to fm10k and we thought community won't like to see 
> this flag introduced into mbuf. If you do agree, we can introduce a new flag.

Why does it need to be specified per-mbuf? The existing config flag added is
global, so a per-mbuf flag shouldn't be needed to get equivalent behaviour.

> So, we step backwards and assume customer will use static configurations to enable
> this feature. After it is enabled, we'll assume app will use FTAG for all packets.

Yes, but instead of compile time option, why not port config-time option instead?

/Bruce

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Chen, Jing D]

Hi, Bruce,

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Thursday, February 25, 2016 9:35 PM
> To: Chen, Jing D <jing.d.chen@intel.com>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Wang, Xiao W
> <xiao.w.wang@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based
> forwarding
> 
> On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> > Hi, Bruce, Thomas,
> >
> > Best Regards,
> > Mark
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas
> Monjalon
> > > Sent: Thursday, February 25, 2016 12:38 AM
> > > To: Richardson, Bruce; Wang, Xiao W
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based
> > > forwarding
> > >
> > > 2016-02-24 15:42, Bruce Richardson:
> > > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote:
> > > > > This patch enables reading sglort info into mbuf for RX and
> > > > > inserting an FTAG at the beginning of the packet for TX. The
> > > > > vlan_tci_outer field selected from rte_mbuf structure for sglort is not
> used in fm10k now.
> > > > > In FTAG based forwarding mode, the switch will forward packets
> > > according
> > > > > to glort info in FTAG rather than mac and vlan table.
> > > > >
> > > > > To activate this feature, user needs to turn
> > > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > > > > to y in common_linuxapp or common_bsdapp. Currently this feature
> > > > > is
> > > supported
> > > > > only on PF, because FM10K_PFVTCTL register is read-only for VF.
> > > > >
> > > > > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> > > >
> > > > Any comments on this patch?
> > > >
> > > > My thoughts: is there a way in which this could be done without
> > > > adding in a
> > > new
> > > > build time config option?
> > >
> > > Bruce, it's simpler to explain that build time options are forbidden
> > > to enable such options.
> > > Or the terrific kid's approach: one day, the Big Build-Option Eater
> > > will come and will eat every undecided features! ;)
> >
> > This feature is trying to use FTAG (a unique tech in fm10k) instead of
> > mac/vlan to forward packets. App need a way to tell PMD driver that
> > which forwarding style it would like to use.
> 
> Why not just specify this in the port configuration at setup time?
> 

Please educate me. I think the port configuration flags are also common to all PMD
Drivers. Is it possible to add a flag like "RTE_USE_FTAG" and pass to PMD driver?

> > So, the best option is to let packets carry a flag in mbuf to tell drive in fast
> path.
> > You can see that this is unique to fm10k and we thought community
> > won't like to see this flag introduced into mbuf. If you do agree, we can
> introduce a new flag.
> 
> Why does it need to be specified per-mbuf? The existing config flag added is
> global, so a per-mbuf flag shouldn't be needed to get equivalent behaviour.
> 
> > So, we step backwards and assume customer will use static
> > configurations to enable this feature. After it is enabled, we'll assume app
> will use FTAG for all packets.
> 
> Yes, but instead of compile time option, why not port config-time option
> instead?
> 
> /Bruce

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Bruce Richardson]

On Thu, Feb 25, 2016 at 03:45:45PM +0000, Chen, Jing D wrote:
> Hi, Bruce,
> 
> > -----Original Message-----
> > From: Richardson, Bruce
> > Sent: Thursday, February 25, 2016 9:35 PM
> > To: Chen, Jing D <jing.d.chen@intel.com>
> > Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Wang, Xiao W
> > <xiao.w.wang@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based
> > forwarding
> > 
> > On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> > > Hi, Bruce, Thomas,
> > >
> > > Best Regards,
> > > Mark
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas
> > Monjalon
> > > > Sent: Thursday, February 25, 2016 12:38 AM
> > > > To: Richardson, Bruce; Wang, Xiao W
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based
> > > > forwarding
> > > >
> > > > 2016-02-24 15:42, Bruce Richardson:
> > > > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote:
> > > > > > This patch enables reading sglort info into mbuf for RX and
> > > > > > inserting an FTAG at the beginning of the packet for TX. The
> > > > > > vlan_tci_outer field selected from rte_mbuf structure for sglort is not
> > used in fm10k now.
> > > > > > In FTAG based forwarding mode, the switch will forward packets
> > > > according
> > > > > > to glort info in FTAG rather than mac and vlan table.
> > > > > >
> > > > > > To activate this feature, user needs to turn
> > > > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > > > > > to y in common_linuxapp or common_bsdapp. Currently this feature
> > > > > > is
> > > > supported
> > > > > > only on PF, because FM10K_PFVTCTL register is read-only for VF.
> > > > > >
> > > > > > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> > > > >
> > > > > Any comments on this patch?
> > > > >
> > > > > My thoughts: is there a way in which this could be done without
> > > > > adding in a
> > > > new
> > > > > build time config option?
> > > >
> > > > Bruce, it's simpler to explain that build time options are forbidden
> > > > to enable such options.
> > > > Or the terrific kid's approach: one day, the Big Build-Option Eater
> > > > will come and will eat every undecided features! ;)
> > >
> > > This feature is trying to use FTAG (a unique tech in fm10k) instead of
> > > mac/vlan to forward packets. App need a way to tell PMD driver that
> > > which forwarding style it would like to use.
> > 
> > Why not just specify this in the port configuration at setup time?
> > 
> 
> Please educate me. I think the port configuration flags are also common to all PMD
> Drivers. Is it possible to add a flag like "RTE_USE_FTAG" and pass to PMD driver?
> 
They are. 
For something PMD specific, like FTAG, it's always a challenge, and I don't know
off the top of my head if there is a simple option. However, given the choice
between an mbuf flag and a port config flag, I'd always choose the former.
Other alternatives would be to have a fm10k specific API in the fm10k driver alone.

I'll let Thomas as ethdev maintainer comment if he has other suggestions as to
how to handle this case. I suspect this won't be the first device-specific 
piece of functionality we need to deal with.

/Bruce

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Wang, Xiao W]

Hi,

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Friday, February 26, 2016 12:14 AM
> To: Chen, Jing D <jing.d.chen@intel.com>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Wang, Xiao W
> <xiao.w.wang@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> 
> On Thu, Feb 25, 2016 at 03:45:45PM +0000, Chen, Jing D wrote:
> > Hi, Bruce,
> >
> > > -----Original Message-----
> > > From: Richardson, Bruce
> > > Sent: Thursday, February 25, 2016 9:35 PM
> > > To: Chen, Jing D <jing.d.chen@intel.com>
> > > Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Wang, Xiao W
> > > <xiao.w.wang@intel.com>; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based
> > > forwarding
> > >
> > > On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> > > > Hi, Bruce, Thomas,
> > > >
> > > > Best Regards,
> > > > Mark
> > > >
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas
> > > Monjalon
> > > > > Sent: Thursday, February 25, 2016 12:38 AM
> > > > > To: Richardson, Bruce; Wang, Xiao W
> > > > > Cc: dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based
> > > > > forwarding
> > > > >
> > > > > 2016-02-24 15:42, Bruce Richardson:
> > > > > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote:
> > > > > > > This patch enables reading sglort info into mbuf for RX and
> > > > > > > inserting an FTAG at the beginning of the packet for TX. The
> > > > > > > vlan_tci_outer field selected from rte_mbuf structure for
> > > > > > > sglort is not
> > > used in fm10k now.
> > > > > > > In FTAG based forwarding mode, the switch will forward
> > > > > > > packets
> > > > > according
> > > > > > > to glort info in FTAG rather than mac and vlan table.
> > > > > > >
> > > > > > > To activate this feature, user needs to turn
> > > > > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > > > > > > to y in common_linuxapp or common_bsdapp. Currently this
> > > > > > > feature is
> > > > > supported
> > > > > > > only on PF, because FM10K_PFVTCTL register is read-only for VF.
> > > > > > >
> > > > > > > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> > > > > >
> > > > > > Any comments on this patch?
> > > > > >
> > > > > > My thoughts: is there a way in which this could be done
> > > > > > without adding in a
> > > > > new
> > > > > > build time config option?
> > > > >
> > > > > Bruce, it's simpler to explain that build time options are
> > > > > forbidden to enable such options.
> > > > > Or the terrific kid's approach: one day, the Big Build-Option
> > > > > Eater will come and will eat every undecided features! ;)
> > > >
> > > > This feature is trying to use FTAG (a unique tech in fm10k)
> > > > instead of mac/vlan to forward packets. App need a way to tell PMD
> > > > driver that which forwarding style it would like to use.
> > >
> > > Why not just specify this in the port configuration at setup time?
> > >
> >
> > Please educate me. I think the port configuration flags are also
> > common to all PMD Drivers. Is it possible to add a flag like "RTE_USE_FTAG"
> and pass to PMD driver?
> >
> They are.
> For something PMD specific, like FTAG, it's always a challenge, and I don't
> know off the top of my head if there is a simple option. However, given the
> choice between an mbuf flag and a port config flag, I'd always choose the
> former.
> Other alternatives would be to have a fm10k specific API in the fm10k driver
> alone.
> 
> I'll let Thomas as ethdev maintainer comment if he has other suggestions as to
> how to handle this case. I suspect this won't be the first device-specific piece of
> functionality we need to deal with.
> 
> /Bruce

Whatever method we choose, we have to find a way for the user to express his need
for FTAG, it maybe a build time config option, or a port config flag (no such flag now),
or a fast path flag in mbuf (no such flag now) etc. For the customer Topsec's use case,
they use FTAG for all the TX packets, so all the above methods (per build config, per
port config, per mbuf config) can meet their need. Since the pmd frame work is for
common, it's hard to add new fields only for one specific NIC, so I add a build time
config and make an introduction in the doc.

Thanks for the discussion, Thomas, do you have any suggestions?

BTW, I have found the patch needs to be rebased on head of dpdk-next-net/rel_16_04 since several
fm10k patches were applied recently.

Best Regards,
Xiao

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Thomas Monjalon]

2016-02-26 04:31, Wang, Xiao W:
> From: Richardson, Bruce
> > On Thu, Feb 25, 2016 at 03:45:45PM +0000, Chen, Jing D wrote:
> > > From: Richardson, Bruce
> > > > On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> > > > > This feature is trying to use FTAG (a unique tech in fm10k)
> > > > > instead of mac/vlan to forward packets. App need a way to tell PMD
> > > > > driver that which forwarding style it would like to use.
> > > >
> > > > Why not just specify this in the port configuration at setup time?
> > > >
> > >
> > > Please educate me. I think the port configuration flags are also
> > > common to all PMD Drivers. Is it possible to add a flag like "RTE_USE_FTAG"
> > and pass to PMD driver?
> > >
> > They are.
> > For something PMD specific, like FTAG, it's always a challenge, and I don't
> > know off the top of my head if there is a simple option. However, given the
> > choice between an mbuf flag and a port config flag, I'd always choose the
> > former.
> > Other alternatives would be to have a fm10k specific API in the fm10k driver
> > alone.
> > 
> > I'll let Thomas as ethdev maintainer comment if he has other suggestions as to
> > how to handle this case. I suspect this won't be the first device-specific piece of
> > functionality we need to deal with.
> > 
> > /Bruce
> 
> Whatever method we choose, we have to find a way for the user to express his need
> for FTAG, it maybe a build time config option, or a port config flag (no such flag now),
> or a fast path flag in mbuf (no such flag now) etc. For the customer Topsec's use case,
> they use FTAG for all the TX packets, so all the above methods (per build config, per
> port config, per mbuf config) can meet their need. Since the pmd frame work is for
> common, it's hard to add new fields only for one specific NIC, so I add a build time
> config and make an introduction in the doc.
> 
> Thanks for the discussion, Thomas, do you have any suggestions?

I don't understand why you say this feature is specific to fm10k. Can we
imagine another NIC having this capability?
I think it must be an port configuration, as Bruce suggested.
What about a field in struct rte_eth_conf?

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Wang, Xiao W]

Hi,

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, February 26, 2016 5:06 PM
> To: Wang, Xiao W <xiao.w.wang@intel.com>
> Cc: Richardson, Bruce <bruce.richardson@intel.com>; Chen, Jing D
> <jing.d.chen@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> 
> 2016-02-26 04:31, Wang, Xiao W:
> > From: Richardson, Bruce
> > > On Thu, Feb 25, 2016 at 03:45:45PM +0000, Chen, Jing D wrote:
> > > > From: Richardson, Bruce
> > > > > On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> > > > > > This feature is trying to use FTAG (a unique tech in fm10k)
> > > > > > instead of mac/vlan to forward packets. App need a way to tell
> > > > > > PMD driver that which forwarding style it would like to use.
> > > > >
> > > > > Why not just specify this in the port configuration at setup time?
> > > > >
> > > >
> > > > Please educate me. I think the port configuration flags are also
> > > > common to all PMD Drivers. Is it possible to add a flag like
> "RTE_USE_FTAG"
> > > and pass to PMD driver?
> > > >
> > > They are.
> > > For something PMD specific, like FTAG, it's always a challenge, and
> > > I don't know off the top of my head if there is a simple option.
> > > However, given the choice between an mbuf flag and a port config
> > > flag, I'd always choose the former.
> > > Other alternatives would be to have a fm10k specific API in the
> > > fm10k driver alone.
> > >
> > > I'll let Thomas as ethdev maintainer comment if he has other
> > > suggestions as to how to handle this case. I suspect this won't be
> > > the first device-specific piece of functionality we need to deal with.
> > >
> > > /Bruce
> >
> > Whatever method we choose, we have to find a way for the user to
> > express his need for FTAG, it maybe a build time config option, or a
> > port config flag (no such flag now), or a fast path flag in mbuf (no
> > such flag now) etc. For the customer Topsec's use case, they use FTAG
> > for all the TX packets, so all the above methods (per build config,
> > per port config, per mbuf config) can meet their need. Since the pmd
> > frame work is for common, it's hard to add new fields only for one specific
> NIC, so I add a build time config and make an introduction in the doc.
> >
> > Thanks for the discussion, Thomas, do you have any suggestions?
> 
> I don't understand why you say this feature is specific to fm10k. Can we
> imagine another NIC having this capability?

As you know, fm10k has a switch logic between the Mac and Phy, every packets
Sent out from the host will be switched inside the NIC, other NICs don't have
a switch inside, and the FTAG feature is related to the switch function.

As introduced in the second patch:
The FM10K family of NICs support the addition of a Fabric Tag (FTAG) to carry
special information. The FTAG is placed at the beginning of the frame, it contains
information such as where the packet comes from and goes, and the vlan tag. In
FTAG based forwarding mode, the switch logic forwards packets according to
glort (global resource tag) information, rather than the mac and vlan table.
So this is a feature specific to fm10k.

Best Regards,
Xiao
> I think it must be an port configuration, as Bruce suggested.
> What about a field in struct rte_eth_conf?

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Bruce Richardson]

On Fri, Feb 26, 2016 at 09:24:06AM +0000, Wang, Xiao W wrote:
> Hi,
> 
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Friday, February 26, 2016 5:06 PM
> > To: Wang, Xiao W <xiao.w.wang@intel.com>
> > Cc: Richardson, Bruce <bruce.richardson@intel.com>; Chen, Jing D
> > <jing.d.chen@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> > 
> > 2016-02-26 04:31, Wang, Xiao W:
> > > From: Richardson, Bruce
> > > > On Thu, Feb 25, 2016 at 03:45:45PM +0000, Chen, Jing D wrote:
> > > > > From: Richardson, Bruce
> > > > > > On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> > > > > > > This feature is trying to use FTAG (a unique tech in fm10k)
> > > > > > > instead of mac/vlan to forward packets. App need a way to tell
> > > > > > > PMD driver that which forwarding style it would like to use.
> > > > > >
> > > > > > Why not just specify this in the port configuration at setup time?
> > > > > >
> > > > >
> > > > > Please educate me. I think the port configuration flags are also
> > > > > common to all PMD Drivers. Is it possible to add a flag like
> > "RTE_USE_FTAG"
> > > > and pass to PMD driver?
> > > > >
> > > > They are.
> > > > For something PMD specific, like FTAG, it's always a challenge, and
> > > > I don't know off the top of my head if there is a simple option.
> > > > However, given the choice between an mbuf flag and a port config
> > > > flag, I'd always choose the former.
> > > > Other alternatives would be to have a fm10k specific API in the
> > > > fm10k driver alone.
> > > >
> > > > I'll let Thomas as ethdev maintainer comment if he has other
> > > > suggestions as to how to handle this case. I suspect this won't be
> > > > the first device-specific piece of functionality we need to deal with.
> > > >
> > > > /Bruce
> > >
> > > Whatever method we choose, we have to find a way for the user to
> > > express his need for FTAG, it maybe a build time config option, or a
> > > port config flag (no such flag now), or a fast path flag in mbuf (no
> > > such flag now) etc. For the customer Topsec's use case, they use FTAG
> > > for all the TX packets, so all the above methods (per build config,
> > > per port config, per mbuf config) can meet their need. Since the pmd
> > > frame work is for common, it's hard to add new fields only for one specific
> > NIC, so I add a build time config and make an introduction in the doc.
> > >
> > > Thanks for the discussion, Thomas, do you have any suggestions?
> > 
> > I don't understand why you say this feature is specific to fm10k. Can we
> > imagine another NIC having this capability?
> 
> As you know, fm10k has a switch logic between the Mac and Phy, every packets
> Sent out from the host will be switched inside the NIC, other NICs don't have
> a switch inside, and the FTAG feature is related to the switch function.
> 
> As introduced in the second patch:
> The FM10K family of NICs support the addition of a Fabric Tag (FTAG) to carry
> special information. The FTAG is placed at the beginning of the frame, it contains
> information such as where the packet comes from and goes, and the vlan tag. In
> FTAG based forwarding mode, the switch logic forwards packets according to
> glort (global resource tag) information, rather than the mac and vlan table.
> So this is a feature specific to fm10k.
> 
> Best Regards,
> Xiao

If it is fm10k specific, how about just adding a public function to the fm10k
driver to turn it on. The user app will be non-portable across NICs, but
that's the price of using nic-specific features.

/Bruce

> > I think it must be an port configuration, as Bruce suggested.
> > What about a field in struct rte_eth_conf?

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[David Marchand]

On Fri, Feb 26, 2016 at 3:48 PM, Bruce Richardson
<bruce.richardson@intel.com> wrote:
> On Fri, Feb 26, 2016 at 09:24:06AM +0000, Wang, Xiao W wrote:
>> Hi,
>> > > Thanks for the discussion, Thomas, do you have any suggestions?
>> >
>> > I don't understand why you say this feature is specific to fm10k. Can we
>> > imagine another NIC having this capability?
>>
>> As you know, fm10k has a switch logic between the Mac and Phy, every packets
>> Sent out from the host will be switched inside the NIC, other NICs don't have
>> a switch inside, and the FTAG feature is related to the switch function.
>>
>> As introduced in the second patch:
>> The FM10K family of NICs support the addition of a Fabric Tag (FTAG) to carry
>> special information. The FTAG is placed at the beginning of the frame, it contains
>> information such as where the packet comes from and goes, and the vlan tag. In
>> FTAG based forwarding mode, the switch logic forwards packets according to
>> glort (global resource tag) information, rather than the mac and vlan table.
>> So this is a feature specific to fm10k.
>
> If it is fm10k specific, how about just adding a public function to the fm10k
> driver to turn it on. The user app will be non-portable across NICs, but
> that's the price of using nic-specific features.

What about using a devargs ?
Something like :
-w xxxx:xx:xx.x,enable_ftag=1

The application still needs to know about this to enable it, but that
sounds better to me.
The only issue is that it can't work with hotplug at the moment.


-- 
David Marchand

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Bruce Richardson]

On Fri, Feb 26, 2016 at 04:00:49PM +0100, David Marchand wrote:
> On Fri, Feb 26, 2016 at 3:48 PM, Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> > On Fri, Feb 26, 2016 at 09:24:06AM +0000, Wang, Xiao W wrote:
> >> Hi,
> >> > > Thanks for the discussion, Thomas, do you have any suggestions?
> >> >
> >> > I don't understand why you say this feature is specific to fm10k. Can we
> >> > imagine another NIC having this capability?
> >>
> >> As you know, fm10k has a switch logic between the Mac and Phy, every packets
> >> Sent out from the host will be switched inside the NIC, other NICs don't have
> >> a switch inside, and the FTAG feature is related to the switch function.
> >>
> >> As introduced in the second patch:
> >> The FM10K family of NICs support the addition of a Fabric Tag (FTAG) to carry
> >> special information. The FTAG is placed at the beginning of the frame, it contains
> >> information such as where the packet comes from and goes, and the vlan tag. In
> >> FTAG based forwarding mode, the switch logic forwards packets according to
> >> glort (global resource tag) information, rather than the mac and vlan table.
> >> So this is a feature specific to fm10k.
> >
> > If it is fm10k specific, how about just adding a public function to the fm10k
> > driver to turn it on. The user app will be non-portable across NICs, but
> > that's the price of using nic-specific features.
> 
> What about using a devargs ?
> Something like :
> -w xxxx:xx:xx.x,enable_ftag=1
> 
> The application still needs to know about this to enable it, but that
> sounds better to me.
> The only issue is that it can't work with hotplug at the moment.
>
Seems a good enough solution to me. Xiao, any other thoughts?

/Bruce

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Wang, Xiao W]

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Saturday, February 27, 2016 12:33 AM
> To: David Marchand <david.marchand@6wind.com>
> Cc: Wang, Xiao W <xiao.w.wang@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> 
> On Fri, Feb 26, 2016 at 04:00:49PM +0100, David Marchand wrote:
> > On Fri, Feb 26, 2016 at 3:48 PM, Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > > On Fri, Feb 26, 2016 at 09:24:06AM +0000, Wang, Xiao W wrote:
> > >> Hi,
> > >> > > Thanks for the discussion, Thomas, do you have any suggestions?
> > >> >
> > >> > I don't understand why you say this feature is specific to fm10k.
> > >> > Can we imagine another NIC having this capability?
> > >>
> > >> As you know, fm10k has a switch logic between the Mac and Phy,
> > >> every packets Sent out from the host will be switched inside the
> > >> NIC, other NICs don't have a switch inside, and the FTAG feature is related
> to the switch function.
> > >>
> > >> As introduced in the second patch:
> > >> The FM10K family of NICs support the addition of a Fabric Tag
> > >> (FTAG) to carry special information. The FTAG is placed at the
> > >> beginning of the frame, it contains information such as where the
> > >> packet comes from and goes, and the vlan tag. In FTAG based
> > >> forwarding mode, the switch logic forwards packets according to glort
> (global resource tag) information, rather than the mac and vlan table.
> > >> So this is a feature specific to fm10k.
> > >
> > > If it is fm10k specific, how about just adding a public function to
> > > the fm10k driver to turn it on. The user app will be non-portable
> > > across NICs, but that's the price of using nic-specific features.
> >
> > What about using a devargs ?
> > Something like :
> > -w xxxx:xx:xx.x,enable_ftag=1
> >
> > The application still needs to know about this to enable it, but that
> > sounds better to me.
> > The only issue is that it can't work with hotplug at the moment.
> >
> Seems a good enough solution to me. Xiao, any other thoughts?
> 
> /Bruce

I also agree with the devargs solution, in this way, the build time config can
be removed and we don't need to add extra fields into ethdev.
I'll rework the patch, thanks for the suggestions.

Best Regards,
Xiao

Re: [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Thomas Monjalon]

2016-02-26 09:24, Wang, Xiao W:
> Hi,
> 
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Friday, February 26, 2016 5:06 PM
> > To: Wang, Xiao W <xiao.w.wang@intel.com>
> > Cc: Richardson, Bruce <bruce.richardson@intel.com>; Chen, Jing D
> > <jing.d.chen@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> > 
> > 2016-02-26 04:31, Wang, Xiao W:
> > > From: Richardson, Bruce
> > > > On Thu, Feb 25, 2016 at 03:45:45PM +0000, Chen, Jing D wrote:
> > > > > From: Richardson, Bruce
> > > > > > On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> > > > > > > This feature is trying to use FTAG (a unique tech in fm10k)
> > > > > > > instead of mac/vlan to forward packets. App need a way to tell
> > > > > > > PMD driver that which forwarding style it would like to use.
> > > > > >
> > > > > > Why not just specify this in the port configuration at setup time?
> > > > > >
> > > > >
> > > > > Please educate me. I think the port configuration flags are also
> > > > > common to all PMD Drivers. Is it possible to add a flag like
> > "RTE_USE_FTAG"
> > > > and pass to PMD driver?
> > > > >
> > > > They are.
> > > > For something PMD specific, like FTAG, it's always a challenge, and
> > > > I don't know off the top of my head if there is a simple option.
> > > > However, given the choice between an mbuf flag and a port config
> > > > flag, I'd always choose the former.
> > > > Other alternatives would be to have a fm10k specific API in the
> > > > fm10k driver alone.
> > > >
> > > > I'll let Thomas as ethdev maintainer comment if he has other
> > > > suggestions as to how to handle this case. I suspect this won't be
> > > > the first device-specific piece of functionality we need to deal with.
> > > >
> > > > /Bruce
> > >
> > > Whatever method we choose, we have to find a way for the user to
> > > express his need for FTAG, it maybe a build time config option, or a
> > > port config flag (no such flag now), or a fast path flag in mbuf (no
> > > such flag now) etc. For the customer Topsec's use case, they use FTAG
> > > for all the TX packets, so all the above methods (per build config,
> > > per port config, per mbuf config) can meet their need. Since the pmd
> > > frame work is for common, it's hard to add new fields only for one specific
> > NIC, so I add a build time config and make an introduction in the doc.
> > >
> > > Thanks for the discussion, Thomas, do you have any suggestions?
> > 
> > I don't understand why you say this feature is specific to fm10k. Can we
> > imagine another NIC having this capability?
> 
> As you know, fm10k has a switch logic between the Mac and Phy, every packets
> Sent out from the host will be switched inside the NIC, other NICs don't have
> a switch inside, and the FTAG feature is related to the switch function.
> 
> As introduced in the second patch:
> The FM10K family of NICs support the addition of a Fabric Tag (FTAG) to carry
> special information. The FTAG is placed at the beginning of the frame, it contains
> information such as where the packet comes from and goes, and the vlan tag. In
> FTAG based forwarding mode, the switch logic forwards packets according to
> glort (global resource tag) information, rather than the mac and vlan table.
> So this is a feature specific to fm10k.

No I still don't think you should consider it specific to fm10k.
But yes it is specific to a switch device.
I'm OK to have a structure for switch configuration in ethdev.

[PATCH v4 0/3] fm10k: enable FTAG based forwarding

[Wang Xiao W]

v4:
* Removed the build time config option, used devargs to config FTAG.
* Rebased on head of dpdk-next-net/rel_16_04 branch.

v3:
* Removed "\n" in PMD_INIT_LOG.
* Returned "-ENOTSUP" instead of -1 in VF FTAG use case.

v2:
* Gave an error message for VF FTAG use case.
* Added a notice in the doc to emphasize that application should ensure
  an appropriate FTAG for every frame in FTAG based forwarding mode.

Wang Xiao W (3):
  fm10k: enable FTAG based forwarding
  doc: add introduction for fm10k FTAG based forwarding
  doc: update release note for fm10k FTAG support

 doc/guides/nics/fm10k.rst              | 16 +++++++++++++-
 doc/guides/rel_notes/release_16_04.rst |  2 ++
 drivers/net/fm10k/fm10k.h              |  2 ++
 drivers/net/fm10k/fm10k_ethdev.c       | 38 +++++++++++++++++++++++++++++++++-
 drivers/net/fm10k/fm10k_rxtx.c         | 15 ++++++++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c     |  4 ++++
 6 files changed, 75 insertions(+), 2 deletions(-)

-- 
1.9.3

[PATCH v4 1/3] fm10k: enable FTAG based forwarding

[Wang Xiao W]

This patch enables reading sglort info into mbuf for RX and inserting
an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
selected from rte_mbuf structure for sglort is not used in fm10k now.
In FTAG based forwarding mode, the switch will forward packets according
to glort info in FTAG rather than mac and vlan table.

To activate this feature, user needs to pass a devargs parameter to eal
for fm10k device like "-w 0000:84:00.0,enable_ftag=1". Currently this
feature is supported only on PF, because FM10K_PFVTCTL register is
read-only for VF.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
Acked-by: Jing Chen <jing.d.chen@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
---
 drivers/net/fm10k/fm10k.h          |  2 ++
 drivers/net/fm10k/fm10k_ethdev.c   | 38 +++++++++++++++++++++++++++++++++++++-
 drivers/net/fm10k/fm10k_rxtx.c     | 15 +++++++++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c |  4 ++++
 4 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
index 770d6ba..05aa1a2 100644
--- a/drivers/net/fm10k/fm10k.h
+++ b/drivers/net/fm10k/fm10k.h
@@ -204,6 +204,7 @@ struct fm10k_rx_queue {
 	uint8_t port_id;
 	uint8_t drop_en;
 	uint8_t rx_deferred_start; /* don't start this queue in dev start. */
+	uint16_t rx_ftag_en; /* indicates FTAG RX supported */
 };
 
 /*
@@ -240,6 +241,7 @@ struct fm10k_tx_queue {
 	uint8_t port_id;
 	uint8_t tx_deferred_start; /** don't start this queue in dev start. */
 	uint16_t queue_id;
+	uint16_t tx_ftag_en; /* indicates FTAG TX supported */
 };
 
 struct fm10k_txq_ops {
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 3c1e1d6..963a8af 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -79,6 +79,7 @@ static void fm10k_tx_queue_release(void *queue);
 static void fm10k_rx_queue_release(void *queue);
 static void fm10k_set_rx_function(struct rte_eth_dev *dev);
 static void fm10k_set_tx_function(struct rte_eth_dev *dev);
+static int fm10k_check_ftag(struct rte_devargs *devargs);
 
 struct fm10k_xstats_name_off {
 	char name[RTE_ETH_XSTATS_NAME_SIZE];
@@ -668,6 +669,18 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
 			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
 			return -1;
 		}
+		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
+		 * register is read-only for VF.
+		 */
+		if (fm10k_check_ftag(dev->pci_dev->devargs)) {
+			if (hw->mac.type == fm10k_mac_pf)
+				FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
+						FM10K_PFVTCTL_FTAG_DESC_ENABLE);
+			else {
+				PMD_INIT_LOG(ERR, "VF FTAG is not supported.");
+				return -ENOTSUP;
+			}
+		}
 
 		/* set location and size for descriptor ring */
 		FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
@@ -2597,15 +2610,32 @@ static const struct eth_dev_ops fm10k_eth_dev_ops = {
 	.rss_hash_conf_get	= fm10k_rss_hash_conf_get,
 };
 
+static int
+fm10k_check_ftag(struct rte_devargs *devargs)
+{
+	if (devargs == NULL)
+		return 0;
+
+	if (strstr(devargs->args, "enable_ftag=1") == NULL)
+		return 0;
+
+	return 1;
+}
+
 static void __attribute__((cold))
 fm10k_set_tx_function(struct rte_eth_dev *dev)
 {
 	struct fm10k_tx_queue *txq;
 	int i;
 	int use_sse = 1;
+	uint16_t tx_ftag_en = 0;
+
+	if (fm10k_check_ftag(dev->pci_dev->devargs))
+		tx_ftag_en = 1;
 
 	for (i = 0; i < dev->data->nb_tx_queues; i++) {
 		txq = dev->data->tx_queues[i];
+		txq->tx_ftag_en = tx_ftag_en;
 		/* Check if Vector Tx is satisfied */
 		if (fm10k_tx_vec_condition_check(txq)) {
 			use_sse = 0;
@@ -2631,11 +2661,16 @@ fm10k_set_rx_function(struct rte_eth_dev *dev)
 {
 	struct fm10k_dev_info *dev_info = FM10K_DEV_PRIVATE_TO_INFO(dev);
 	uint16_t i, rx_using_sse;
+	uint16_t rx_ftag_en = 0;
+
+	if (fm10k_check_ftag(dev->pci_dev->devargs))
+		rx_ftag_en = 1;
 
 	/* In order to allow Vector Rx there are a few configuration
 	 * conditions to be met.
 	 */
-	if (!fm10k_rx_vec_condition_check(dev) && dev_info->rx_vec_allowed) {
+	if (!fm10k_rx_vec_condition_check(dev) &&
+			dev_info->rx_vec_allowed && !rx_ftag_en) {
 		if (dev->data->scattered_rx)
 			dev->rx_pkt_burst = fm10k_recv_scattered_pkts_vec;
 		else
@@ -2658,6 +2693,7 @@ fm10k_set_rx_function(struct rte_eth_dev *dev)
 		struct fm10k_rx_queue *rxq = dev->data->rx_queues[i];
 
 		rxq->rx_using_sse = rx_using_sse;
+		rxq->rx_ftag_en = rx_ftag_en;
 	}
 }
 
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index 9f832c1..66db5b6 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -152,6 +152,12 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
 		mbuf->vlan_tci = desc.w.vlan;
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		if (q->rx_ftag_en)
+			mbuf->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
 
 		rx_pkts[count] = mbuf;
 		if (++next_dd == q->nb_desc) {
@@ -307,6 +313,13 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		first_seg->ol_flags |= PKT_RX_VLAN_PKT;
 		first_seg->vlan_tci = desc.w.vlan;
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		if (q->rx_ftag_en)
+			first_seg->vlan_tci_outer =
+				rte_le_to_cpu_16(desc.w.sglort);
 
 		/* Prefetch data of first segment, if configured to do so. */
 		rte_packet_prefetch((char *)first_seg->buf_addr +
@@ -498,6 +511,8 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, struct rte_mbuf *mb)
 	q->nb_free -= mb->nb_segs;
 
 	q->hw_ring[q->next_free].flags = 0;
+	if (q->tx_ftag_en)
+		q->hw_ring[q->next_free].flags |= FM10K_TXD_FLAG_FTAG;
 	/* set checksum flags on first descriptor of packet. SCTP checksum
 	 * offload is not supported, but we do not explicitly check for this
 	 * case in favor of greatly simplified processing. */
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 9f178db..267e5b0 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -239,6 +239,7 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
 		return -1;
 
 	return 0;
+
 #else
 	RTE_SET_USED(dev);
 	return -1;
@@ -688,6 +689,9 @@ fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)
 	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) != FM10K_SIMPLE_TX_FLAG)
 		return -1;
 
+	if (txq->tx_ftag_en)
+		return -1;
+
 	return 0;
 }
 
-- 
1.9.3

Re: [PATCH v4 1/3] fm10k: enable FTAG based forwarding

[Thomas Monjalon]

2016-03-01 13:36, Wang Xiao W:
> +static int
> +fm10k_check_ftag(struct rte_devargs *devargs)
> +{
> +       if (devargs == NULL)
> +               return 0;
> +
> +       if (strstr(devargs->args, "enable_ftag=1") == NULL)
> +               return 0;
> +
> +       return 1;
> +}

With strstr(), chenable_ftag=12 will work :)
Please check how to use kvargs.

Re: [PATCH v4 1/3] fm10k: enable FTAG based forwarding

[Wang, Xiao W]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, March 1, 2016 3:36 PM
> To: Wang, Xiao W <xiao.w.wang@intel.com>
> Cc: dev@dpdk.org; Chen, Jing D <jing.d.chen@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/3] fm10k: enable FTAG based forwarding
> 
> 2016-03-01 13:36, Wang Xiao W:
> > +static int
> > +fm10k_check_ftag(struct rte_devargs *devargs) {
> > +       if (devargs == NULL)
> > +               return 0;
> > +
> > +       if (strstr(devargs->args, "enable_ftag=1") == NULL)
> > +               return 0;
> > +
> > +       return 1;
> > +}
> 
> With strstr(), chenable_ftag=12 will work :) Please check how to use kvargs.

OK, it's better to standardize the args string processing. I'll rework it.

Best Regards,
Xiao

Re: [PATCH v4 1/3] fm10k: enable FTAG based forwarding

[Stephen Hemminger]

On Tue,  1 Mar 2016 13:36:39 +0800
Wang Xiao W <xiao.w.wang@intel.com> wrote:

>  
> +static int
> +fm10k_check_ftag(struct rte_devargs *devargs)
> +{
> +	if (devargs == NULL)
> +		return 0;
> +
> +	if (strstr(devargs->args, "enable_ftag=1") == NULL)
> +		return 0;
> +
> +	return 1;
> +}
> +

It is good to see the DPDK keeping up with the leading edge of hardware
support.

My issue is that devargs are the Linux module parameters method of
configuration in the DPDK world.  They are an API only a developer
would love..

 1. It has to be done at boot
 2. Applications have to rewrite (or expect customer) to pass args
 3. Can't be changed at runtime
 4. Can't be selected on per device basis.

Please find a better way.

Re: [PATCH v4 1/3] fm10k: enable FTAG based forwarding

[Wang, Xiao W]

Hi,

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, March 2, 2016 6:38 AM
> To: Wang, Xiao W <xiao.w.wang@intel.com>
> Cc: Chen, Jing D <jing.d.chen@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 1/3] fm10k: enable FTAG based forwarding
> 
> On Tue,  1 Mar 2016 13:36:39 +0800
> Wang Xiao W <xiao.w.wang@intel.com> wrote:
> 
> >
> > +static int
> > +fm10k_check_ftag(struct rte_devargs *devargs) {
> > +	if (devargs == NULL)
> > +		return 0;
> > +
> > +	if (strstr(devargs->args, "enable_ftag=1") == NULL)
> > +		return 0;
> > +
> > +	return 1;
> > +}
> > +
> 
> It is good to see the DPDK keeping up with the leading edge of hardware
> support.
> 
> My issue is that devargs are the Linux module parameters method of
> configuration in the DPDK world.  They are an API only a developer would love..

DPDK supports passing string parameter (devargs) for every pci device to EAL, it's like:
"./test -w 84:00.0,enable_ftag=1 -w 86:00.0,enable_ftag=1 -c f -n 4".
We have discussed (in v3) on how to configure the specific feature for fm10k (by means
of adding a build time config option, or changing the common ethdev structure,
or changing the mbuf structure), neither adding extra build config option nor
changing the common structure looks satisfactory, and we think using devargs is
a good enough solution.

> 
>  1. It has to be done at boot
>  2. Applications have to rewrite (or expect customer) to pass args  3. Can't be
> changed at runtime  4. Can't be selected on per device basis.

Customers configure the FTAG feature according to their need.
We just parse the devargs at dev_start and set FTAG flag for RX/TX queues, we
(or the customers) needn't to change the devargs at runtime.
In DPDK devargs is designed for each pci device, each device has its own pointer
for devargs structure.

Thank you for the comment.

Best Regards,
Xiao

Re: [PATCH v4 1/3] fm10k: enable FTAG based forwarding

[Thomas Monjalon]

2016-03-01 14:37, Stephen Hemminger:
> On Tue,  1 Mar 2016 13:36:39 +0800
> Wang Xiao W <xiao.w.wang@intel.com> wrote:
> > +static int
> > +fm10k_check_ftag(struct rte_devargs *devargs)
> > +{
> > +	if (devargs == NULL)
> > +		return 0;
> > +
> > +	if (strstr(devargs->args, "enable_ftag=1") == NULL)
> > +		return 0;
> > +
> > +	return 1;
> > +}
> 
> It is good to see the DPDK keeping up with the leading edge of hardware
> support.
> 
> My issue is that devargs are the Linux module parameters method of
> configuration in the DPDK world.  They are an API only a developer
> would love..
> 
>  1. It has to be done at boot

For vdev it can be done later.
The devargs can be generalized in the driver model to provide a
configuration interface per device.

>  2. Applications have to rewrite (or expect customer) to pass args

Like said above, if the devargs are correctly implemented, there will
be some API to pass them.

>  3. Can't be changed at runtime

Same point as 1.

>  4. Can't be selected on per device basis.

No. The devargs are args per device.
For PCI, they are currently passed in the whitelist.

> Please find a better way.

Another way would be to extend the configuration structures.
I think it's better to re-think the device configuration and the command line
using some devargs and more functions, ops and structs to configure the really
generic stuff.

This devargs goes in the direction of a flexible configuration, so I'd vote +1.

[PATCH v5 0/2] fm10k: enable FTAG based forwarding

[Wang Xiao W]

v5:
* Used kvargs api to parse the devargs parameter.
* Put release note into the driver patch.

v4:
* Removed the build time config option, used devargs to config FTAG.
* Rebased on head of dpdk-next-net/rel_16_04 branch.

v3:
* Removed "\n" in PMD_INIT_LOG.
* Returned "-ENOTSUP" instead of -1 in VF FTAG use case.

v2:
* Gave an error message for VF FTAG use case.
* Added a notice in the doc to emphasize that application should ensure
  an appropriate FTAG for every frame in FTAG based forwarding mode.

Wang Xiao W (2):
  fm10k: enable FTAG based forwarding
  doc: add introduction for fm10k FTAG based forwarding

 doc/guides/nics/fm10k.rst              | 16 ++++++++-
 doc/guides/rel_notes/release_16_04.rst |  2 ++
 drivers/net/fm10k/fm10k.h              |  2 ++
 drivers/net/fm10k/fm10k_ethdev.c       | 65 +++++++++++++++++++++++++++++++++-
 drivers/net/fm10k/fm10k_rxtx.c         | 15 ++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c     |  3 ++
 6 files changed, 101 insertions(+), 2 deletions(-)

-- 
1.9.3

[PATCH v5 1/2] fm10k: enable FTAG based forwarding

[Wang Xiao W]

This patch enables reading sglort info into mbuf for RX and inserting
an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
selected from rte_mbuf structure for sglort is not used in fm10k now.
In FTAG based forwarding mode, the switch will forward packets according
to glort info in FTAG rather than mac and vlan table.

To activate this feature, user needs to pass a devargs parameter to eal
for fm10k device like "-w 0000:84:00.0,enable_ftag=1". Currently this
feature is supported only on PF, because FM10K_PFVTCTL register is
read-only for VF.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
Acked-by: Jing Chen <jing.d.chen@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
---
 doc/guides/rel_notes/release_16_04.rst |  2 ++
 drivers/net/fm10k/fm10k.h              |  2 ++
 drivers/net/fm10k/fm10k_ethdev.c       | 65 +++++++++++++++++++++++++++++++++-
 drivers/net/fm10k/fm10k_rxtx.c         | 15 ++++++++
 drivers/net/fm10k/fm10k_rxtx_vec.c     |  3 ++
 5 files changed, 86 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
index 73494f9..c3ee8b1 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -49,6 +49,8 @@ This section should contain new features added in this release. Sample format:
 
   * Free multiple mbufs at a time to reduce freeing mbuf cycles.
 
+* **Added fm10k FTAG based forwarding support.**
+
 * **Added new new X550EM_a devices.**
 
   Added new X550EM_a devices and their mac types, X550EM_a and X550EM_a_vf.
diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
index 770d6ba..05aa1a2 100644
--- a/drivers/net/fm10k/fm10k.h
+++ b/drivers/net/fm10k/fm10k.h
@@ -204,6 +204,7 @@ struct fm10k_rx_queue {
 	uint8_t port_id;
 	uint8_t drop_en;
 	uint8_t rx_deferred_start; /* don't start this queue in dev start. */
+	uint16_t rx_ftag_en; /* indicates FTAG RX supported */
 };
 
 /*
@@ -240,6 +241,7 @@ struct fm10k_tx_queue {
 	uint8_t port_id;
 	uint8_t tx_deferred_start; /** don't start this queue in dev start. */
 	uint16_t queue_id;
+	uint16_t tx_ftag_en; /* indicates FTAG TX supported */
 };
 
 struct fm10k_txq_ops {
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 3c1e1d6..ad6cad9 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -37,6 +37,7 @@
 #include <rte_string_fns.h>
 #include <rte_dev.h>
 #include <rte_spinlock.h>
+#include <rte_kvargs.h>
 
 #include "fm10k.h"
 #include "base/fm10k_api.h"
@@ -79,6 +80,7 @@ static void fm10k_tx_queue_release(void *queue);
 static void fm10k_rx_queue_release(void *queue);
 static void fm10k_set_rx_function(struct rte_eth_dev *dev);
 static void fm10k_set_tx_function(struct rte_eth_dev *dev);
+static int fm10k_check_ftag(struct rte_devargs *devargs);
 
 struct fm10k_xstats_name_off {
 	char name[RTE_ETH_XSTATS_NAME_SIZE];
@@ -668,6 +670,19 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
 			PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
 			return -1;
 		}
+		/* Enable use of FTAG bit in TX descriptor, PFVTCTL
+		 * register is read-only for VF.
+		 */
+		if (fm10k_check_ftag(dev->pci_dev->devargs)) {
+			if (hw->mac.type == fm10k_mac_pf) {
+				FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
+						FM10K_PFVTCTL_FTAG_DESC_ENABLE);
+				PMD_INIT_LOG(DEBUG, "FTAG mode is enabled");
+			} else {
+				PMD_INIT_LOG(ERR, "VF FTAG is not supported.");
+				return -ENOTSUP;
+			}
+		}
 
 		/* set location and size for descriptor ring */
 		FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
@@ -2597,15 +2612,57 @@ static const struct eth_dev_ops fm10k_eth_dev_ops = {
 	.rss_hash_conf_get	= fm10k_rss_hash_conf_get,
 };
 
+static int ftag_check_handler(__rte_unused const char *key,
+		const char *value, __rte_unused void *opaque)
+{
+	if (strcmp(value, "1"))
+		return -1;
+
+	return 0;
+}
+
+static int
+fm10k_check_ftag(struct rte_devargs *devargs)
+{
+	struct rte_kvargs *kvlist;
+	const char *ftag_key = "enable_ftag";
+
+	if (devargs == NULL)
+		return 0;
+
+	kvlist = rte_kvargs_parse(devargs->args, NULL);
+	if (kvlist == NULL)
+		return 0;
+
+	if (!rte_kvargs_count(kvlist, ftag_key)) {
+		rte_kvargs_free(kvlist);
+		return 0;
+	}
+	/* FTAG is enabled when there's key-value pair: enable_ftag=1 */
+	if (rte_kvargs_process(kvlist, ftag_key,
+				ftag_check_handler, NULL) < 0) {
+		rte_kvargs_free(kvlist);
+		return 0;
+	}
+	rte_kvargs_free(kvlist);
+
+	return 1;
+}
+
 static void __attribute__((cold))
 fm10k_set_tx_function(struct rte_eth_dev *dev)
 {
 	struct fm10k_tx_queue *txq;
 	int i;
 	int use_sse = 1;
+	uint16_t tx_ftag_en = 0;
+
+	if (fm10k_check_ftag(dev->pci_dev->devargs))
+		tx_ftag_en = 1;
 
 	for (i = 0; i < dev->data->nb_tx_queues; i++) {
 		txq = dev->data->tx_queues[i];
+		txq->tx_ftag_en = tx_ftag_en;
 		/* Check if Vector Tx is satisfied */
 		if (fm10k_tx_vec_condition_check(txq)) {
 			use_sse = 0;
@@ -2631,11 +2688,16 @@ fm10k_set_rx_function(struct rte_eth_dev *dev)
 {
 	struct fm10k_dev_info *dev_info = FM10K_DEV_PRIVATE_TO_INFO(dev);
 	uint16_t i, rx_using_sse;
+	uint16_t rx_ftag_en = 0;
+
+	if (fm10k_check_ftag(dev->pci_dev->devargs))
+		rx_ftag_en = 1;
 
 	/* In order to allow Vector Rx there are a few configuration
 	 * conditions to be met.
 	 */
-	if (!fm10k_rx_vec_condition_check(dev) && dev_info->rx_vec_allowed) {
+	if (!fm10k_rx_vec_condition_check(dev) &&
+			dev_info->rx_vec_allowed && !rx_ftag_en) {
 		if (dev->data->scattered_rx)
 			dev->rx_pkt_burst = fm10k_recv_scattered_pkts_vec;
 		else
@@ -2658,6 +2720,7 @@ fm10k_set_rx_function(struct rte_eth_dev *dev)
 		struct fm10k_rx_queue *rxq = dev->data->rx_queues[i];
 
 		rxq->rx_using_sse = rx_using_sse;
+		rxq->rx_ftag_en = rx_ftag_en;
 	}
 }
 
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index 9f832c1..66db5b6 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -152,6 +152,12 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		mbuf->ol_flags |= PKT_RX_VLAN_PKT;
 		mbuf->vlan_tci = desc.w.vlan;
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		if (q->rx_ftag_en)
+			mbuf->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
 
 		rx_pkts[count] = mbuf;
 		if (++next_dd == q->nb_desc) {
@@ -307,6 +313,13 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
 		 */
 		first_seg->ol_flags |= PKT_RX_VLAN_PKT;
 		first_seg->vlan_tci = desc.w.vlan;
+		/**
+		 * mbuf->vlan_tci_outer is an idle field in fm10k driver,
+		 * so it can be selected to store sglort value.
+		 */
+		if (q->rx_ftag_en)
+			first_seg->vlan_tci_outer =
+				rte_le_to_cpu_16(desc.w.sglort);
 
 		/* Prefetch data of first segment, if configured to do so. */
 		rte_packet_prefetch((char *)first_seg->buf_addr +
@@ -498,6 +511,8 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, struct rte_mbuf *mb)
 	q->nb_free -= mb->nb_segs;
 
 	q->hw_ring[q->next_free].flags = 0;
+	if (q->tx_ftag_en)
+		q->hw_ring[q->next_free].flags |= FM10K_TXD_FLAG_FTAG;
 	/* set checksum flags on first descriptor of packet. SCTP checksum
 	 * offload is not supported, but we do not explicitly check for this
 	 * case in favor of greatly simplified processing. */
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 9f178db..1c78725 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -688,6 +688,9 @@ fm10k_tx_vec_condition_check(struct fm10k_tx_queue *txq)
 	if ((txq->txq_flags & FM10K_SIMPLE_TX_FLAG) != FM10K_SIMPLE_TX_FLAG)
 		return -1;
 
+	if (txq->tx_ftag_en)
+		return -1;
+
 	return 0;
 }
 
-- 
1.9.3

Re: [PATCH v5 1/2] fm10k: enable FTAG based forwarding

[Bruce Richardson]

On Wed, Mar 02, 2016 at 07:19:13PM +0800, Wang Xiao W wrote:
> This patch enables reading sglort info into mbuf for RX and inserting
> an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> selected from rte_mbuf structure for sglort is not used in fm10k now.
> In FTAG based forwarding mode, the switch will forward packets according
> to glort info in FTAG rather than mac and vlan table.
> 
> To activate this feature, user needs to pass a devargs parameter to eal
> for fm10k device like "-w 0000:84:00.0,enable_ftag=1". Currently this
> feature is supported only on PF, because FM10K_PFVTCTL register is
> read-only for VF.
> 
> Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> Acked-by: Jing Chen <jing.d.chen@intel.com>
> Acked-by: John McNamara <john.mcnamara@intel.com>

Not sure the acks are correctly recorded here. John has acked the documentation
patch (2/2), not this patch. I'll fix this on apply.
Next time, please try to record the acks more accurately.

Thanks,
/Bruce

[PATCH v5 2/2] doc: add introduction for fm10k FTAG based forwarding

[Wang Xiao W]

Add a brief introduction on FTAG, describe what's FTAG and how it works
in forwarding.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 doc/guides/nics/fm10k.rst | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst
index dc5cb6e..89d6ae2 100644
--- a/doc/guides/nics/fm10k.rst
+++ b/doc/guides/nics/fm10k.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-    Copyright(c) 2015 Intel Corporation. All rights reserved.
+    Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
     All rights reserved.
 
     Redistribution and use in source and binary forms, with or without
@@ -34,6 +34,20 @@ FM10K Poll Mode Driver
 The FM10K poll mode driver library provides support for the Intel FM10000
 (FM10K) family of 40GbE/100GbE adapters.
 
+FTAG Based Forwarding of FM10K
+------------------------------
+
+FTAG Based Forwarding is a unique feature of FM10K. The FM10K family of NICs
+support the addition of a Fabric Tag (FTAG) to carry special information.
+The FTAG is placed at the beginning of the frame, it contains information
+such as where the packet comes from and goes, and the vlan tag. In FTAG based
+forwarding mode, the switch logic forwards packets according to glort (global
+resource tag) information, rather than the mac and vlan table. Currently this
+feature works only on PF.
+
+To enable this feature, the user should pass a devargs parameter to the eal
+like "-w 84:00.0,enable_ftag=1", and the application should make sure an
+appropriate FTAG is inserted for every frame on TX side.
 
 Limitations
 -----------
-- 
1.9.3

Re: [PATCH v5 0/2] fm10k: enable FTAG based forwarding

[Liu, Yong]

Tested-by: Yong Liu <yong.liu@intel.com>

- Tested Branch: dpdk-next-net/rel_16_04
- Tested Commit: 4ac366ba647909c3b71818f9be9db86ba5e871da
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc version 4.8.3 20140911
- CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
- NIC: Intel Corporation Device RedrockCanyou [8086:15a4]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed

- Prerequisites command / instruction:
  Apply fm_ftag unit test patch.
  export Port0 and Port1's GLORT ID to environment variables
    export PORT1_GLORT=0x4200
    export PORT0_GLORT=0x4000

- Case: Ftag forwarding unit test
  Description: check fm10k nic can forwarding packets based on FTAG
  Command / instruction:
    Start test application and run fm10k_ftag_autotest
      test -c f -n 4 -w 83:00.0,enable_ftag=1 -w 85:00.0,enable_ftag=1
      RTE>>fm10k_ftag_autotest
    Send packet to Port0 and verify packet forwarded to Port1
      Receive 1 packets on port 0
      test for FTAG RX passed
      Send out 1 packets with FTAG on port 0
      Receive 1 packets on port 1
      test for FTAG TX passed
      Test OK


> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wang Xiao W
> Sent: Wednesday, March 02, 2016 7:19 PM
> To: Chen, Jing D
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v5 0/2] fm10k: enable FTAG based forwarding
> 
> v5:
> * Used kvargs api to parse the devargs parameter.
> * Put release note into the driver patch.
> 
> v4:
> * Removed the build time config option, used devargs to config FTAG.
> * Rebased on head of dpdk-next-net/rel_16_04 branch.
> 
> v3:
> * Removed "\n" in PMD_INIT_LOG.
> * Returned "-ENOTSUP" instead of -1 in VF FTAG use case.
> 
> v2:
> * Gave an error message for VF FTAG use case.
> * Added a notice in the doc to emphasize that application should ensure
>   an appropriate FTAG for every frame in FTAG based forwarding mode.
> 
> Wang Xiao W (2):
>   fm10k: enable FTAG based forwarding
>   doc: add introduction for fm10k FTAG based forwarding
> 
>  doc/guides/nics/fm10k.rst              | 16 ++++++++-
>  doc/guides/rel_notes/release_16_04.rst |  2 ++
>  drivers/net/fm10k/fm10k.h              |  2 ++
>  drivers/net/fm10k/fm10k_ethdev.c       | 65
> +++++++++++++++++++++++++++++++++-
>  drivers/net/fm10k/fm10k_rxtx.c         | 15 ++++++++
>  drivers/net/fm10k/fm10k_rxtx_vec.c     |  3 ++
>  6 files changed, 101 insertions(+), 2 deletions(-)
> 
> --
> 1.9.3

Re: [PATCH v5 0/2] fm10k: enable FTAG based forwarding

[Wang, Xiao W]

Hi,

We reached a consensus on configuring FTAG by devargs method, any other suggestion
or concern for this patch?

Best Regards,
Xiao

> -----Original Message-----
> From: Liu, Yong
> Sent: Tuesday, March 8, 2016 3:58 PM
> To: Wang, Xiao W <xiao.w.wang@intel.com>; Chen, Jing D
> <jing.d.chen@intel.com>
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v5 0/2] fm10k: enable FTAG based forwarding
> 
> Tested-by: Yong Liu <yong.liu@intel.com>
> 
> - Tested Branch: dpdk-next-net/rel_16_04
> - Tested Commit: 4ac366ba647909c3b71818f9be9db86ba5e871da
> - OS: Fedora20 3.11.10-301.fc20.x86_64
> - GCC: gcc version 4.8.3 20140911
> - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
> - NIC: Intel Corporation Device RedrockCanyou [8086:15a4]
> - Default x86_64-native-linuxapp-gcc configuration
> - Prerequisites:
> - Total 1 cases, 1 passed, 0 failed
> 
> - Prerequisites command / instruction:
>   Apply fm_ftag unit test patch.
>   export Port0 and Port1's GLORT ID to environment variables
>     export PORT1_GLORT=0x4200
>     export PORT0_GLORT=0x4000
> 
> - Case: Ftag forwarding unit test
>   Description: check fm10k nic can forwarding packets based on FTAG
>   Command / instruction:
>     Start test application and run fm10k_ftag_autotest
>       test -c f -n 4 -w 83:00.0,enable_ftag=1 -w 85:00.0,enable_ftag=1
>       RTE>>fm10k_ftag_autotest
>     Send packet to Port0 and verify packet forwarded to Port1
>       Receive 1 packets on port 0
>       test for FTAG RX passed
>       Send out 1 packets with FTAG on port 0
>       Receive 1 packets on port 1
>       test for FTAG TX passed
>       Test OK
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wang Xiao W
> > Sent: Wednesday, March 02, 2016 7:19 PM
> > To: Chen, Jing D
> > Cc: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH v5 0/2] fm10k: enable FTAG based forwarding
> >
> > v5:
> > * Used kvargs api to parse the devargs parameter.
> > * Put release note into the driver patch.
> >
> > v4:
> > * Removed the build time config option, used devargs to config FTAG.
> > * Rebased on head of dpdk-next-net/rel_16_04 branch.
> >
> > v3:
> > * Removed "\n" in PMD_INIT_LOG.
> > * Returned "-ENOTSUP" instead of -1 in VF FTAG use case.
> >
> > v2:
> > * Gave an error message for VF FTAG use case.
> > * Added a notice in the doc to emphasize that application should ensure
> >   an appropriate FTAG for every frame in FTAG based forwarding mode.
> >
> > Wang Xiao W (2):
> >   fm10k: enable FTAG based forwarding
> >   doc: add introduction for fm10k FTAG based forwarding
> >
> >  doc/guides/nics/fm10k.rst              | 16 ++++++++-
> >  doc/guides/rel_notes/release_16_04.rst |  2 ++
> >  drivers/net/fm10k/fm10k.h              |  2 ++
> >  drivers/net/fm10k/fm10k_ethdev.c       | 65
> > +++++++++++++++++++++++++++++++++-
> >  drivers/net/fm10k/fm10k_rxtx.c         | 15 ++++++++
> >  drivers/net/fm10k/fm10k_rxtx_vec.c     |  3 ++
> >  6 files changed, 101 insertions(+), 2 deletions(-)
> >
> > --
> > 1.9.3

Re: [PATCH v5 0/2] fm10k: enable FTAG based forwarding

[Bruce Richardson]

On Wed, Mar 02, 2016 at 07:19:12PM +0800, Wang Xiao W wrote:
> v5:
> * Used kvargs api to parse the devargs parameter.
> * Put release note into the driver patch.
> 
> v4:
> * Removed the build time config option, used devargs to config FTAG.
> * Rebased on head of dpdk-next-net/rel_16_04 branch.
> 
> v3:
> * Removed "\n" in PMD_INIT_LOG.
> * Returned "-ENOTSUP" instead of -1 in VF FTAG use case.
> 
> v2:
> * Gave an error message for VF FTAG use case.
> * Added a notice in the doc to emphasize that application should ensure
>   an appropriate FTAG for every frame in FTAG based forwarding mode.
> 
> Wang Xiao W (2):
>   fm10k: enable FTAG based forwarding
>   doc: add introduction for fm10k FTAG based forwarding
>
Applied to dpdk-next-net/rel_16_04

/Bruce

[PATCH v4 2/3] doc: add introduction for fm10k FTAG based forwarding

[Wang Xiao W]

Add a brief introduction on FTAG, describe what's FTAG and how it works
in forwarding.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 doc/guides/nics/fm10k.rst | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst
index dc5cb6e..89d6ae2 100644
--- a/doc/guides/nics/fm10k.rst
+++ b/doc/guides/nics/fm10k.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-    Copyright(c) 2015 Intel Corporation. All rights reserved.
+    Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
     All rights reserved.
 
     Redistribution and use in source and binary forms, with or without
@@ -34,6 +34,20 @@ FM10K Poll Mode Driver
 The FM10K poll mode driver library provides support for the Intel FM10000
 (FM10K) family of 40GbE/100GbE adapters.
 
+FTAG Based Forwarding of FM10K
+------------------------------
+
+FTAG Based Forwarding is a unique feature of FM10K. The FM10K family of NICs
+support the addition of a Fabric Tag (FTAG) to carry special information.
+The FTAG is placed at the beginning of the frame, it contains information
+such as where the packet comes from and goes, and the vlan tag. In FTAG based
+forwarding mode, the switch logic forwards packets according to glort (global
+resource tag) information, rather than the mac and vlan table. Currently this
+feature works only on PF.
+
+To enable this feature, the user should pass a devargs parameter to the eal
+like "-w 84:00.0,enable_ftag=1", and the application should make sure an
+appropriate FTAG is inserted for every frame on TX side.
 
 Limitations
 -----------
-- 
1.9.3

[PATCH v4 3/3] doc: update release note for fm10k FTAG support

[Wang Xiao W]

Update the 16_04 release note.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 doc/guides/rel_notes/release_16_04.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst
index 73494f9..c3ee8b1 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -49,6 +49,8 @@ This section should contain new features added in this release. Sample format:
 
   * Free multiple mbufs at a time to reduce freeing mbuf cycles.
 
+* **Added fm10k FTAG based forwarding support.**
+
 * **Added new new X550EM_a devices.**
 
   Added new X550EM_a devices and their mac types, X550EM_a and X550EM_a_vf.
-- 
1.9.3

[PATCH v3 2/3] doc: add introduction for fm10k FTAG based forwarding

[Wang Xiao W]

Add a brief introduction on FTAG, describe what's FTAG and how it works
in forwarding.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 doc/guides/nics/fm10k.rst | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst
index 4206b7f..6f61482 100644
--- a/doc/guides/nics/fm10k.rst
+++ b/doc/guides/nics/fm10k.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-    Copyright(c) 2015 Intel Corporation. All rights reserved.
+    Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
     All rights reserved.
 
     Redistribution and use in source and binary forms, with or without
@@ -34,6 +34,20 @@ FM10K Poll Mode Driver
 The FM10K poll mode driver library provides support for the Intel FM10000
 (FM10K) family of 40GbE/100GbE adapters.
 
+FTAG Based Forwarding of FM10K
+------------------------------
+
+FTAG Based Forwarding is a unique feature of FM10K. The FM10K family of NICs
+support the addition of a Fabric Tag (FTAG) to carry special information.
+The FTAG is placed at the beginning of the frame, it contains information
+such as where the packet comes from and goes, and the vlan tag. In FTAG based
+forwarding mode, the switch logic forwards packets according to glort (global
+resource tag) information, rather than the mac and vlan table. Currently this
+feature works only on PF.
+
+To enable this feature, turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD`` to y in the
+configuration file, and the application should make sure an appropriate FTAG is
+inserted for every frame on TX side.
 
 Limitations
 -----------
-- 
1.9.3

Re: [PATCH v3 2/3] doc: add introduction for fm10k FTAG based forwarding

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wang Xiao W
> Sent: Thursday, February 4, 2016 3:39 AM
> To: Chen, Jing D <jing.d.chen@intel.com>
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v3 2/3] doc: add introduction for fm10k FTAG
> based forwarding
> 
> Add a brief introduction on FTAG, describe what's FTAG and how it works in
> forwarding.
> 
> Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>

Acked-by: John McNamara <john.mcnamara@intel.com>

[PATCH v3 3/3] doc: update release note for fm10k FTAG support

[Wang Xiao W]

Update the release note.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 doc/guides/rel_notes/release_2_3.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 7945694..7325230 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,7 @@ This section should contain new features added in this release. Sample format:
 
   Enabled virtio 1.0 support for virtio pmd driver.
 
+* **Added fm10k FTAG based forwarding support.**
 
 Resolved Issues
 ---------------
-- 
1.9.3

Re: [PATCH v3 3/3] doc: update release note for fm10k FTAG support

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wang Xiao W
> Sent: Thursday, February 4, 2016 3:39 AM
> To: Chen, Jing D <jing.d.chen@intel.com>
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v3 3/3] doc: update release note for fm10k FTAG
> support
> 
> Update the release note.
> 
> Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>

Acked-by: John McNamara <john.mcnamara@intel.com>

Re: [PATCH v3 0/3] fm10k: enable FTAG based forwarding

[Chen, Jing D]

Hi, 

Best Regards,
Mark


> -----Original Message-----
> From: Wang, Xiao W
> Sent: Thursday, February 04, 2016 11:39 AM
> To: Chen, Jing D
> Cc: dev@dpdk.org; Qiu, Michael; He, Shaopeng; Wang, Xiao W
> Subject: [PATCH v3 0/3] fm10k: enable FTAG based forwarding
> 
> v3:
> * Removed "\n" in PMD_INIT_LOG.
> 
> * Returned "-ENOTSUP" instead of -1 in VF FTAG use case.
> 
> v2:
> * Gave an error message for VF FTAG use case.
> 
> * Added a notice in the doc to emphasize that application should ensure
>   an appropriate FTAG for every frame in FTAG based forwarding mode.
> 
> Wang Xiao W (3):
>   fm10k: enable FTAG based forwarding
>   doc: add introduction for fm10k FTAG based forwarding
>   doc: update release note for fm10k FTAG support
> 
>  config/common_bsdapp                 |  1 +
>  config/common_linuxapp               |  1 +
>  doc/guides/nics/fm10k.rst            | 16 +++++++++++++++-
>  doc/guides/rel_notes/release_2_3.rst |  1 +
>  drivers/net/fm10k/fm10k_ethdev.c     | 12 ++++++++++++
>  drivers/net/fm10k/fm10k_rxtx.c       | 17 +++++++++++++++++
>  drivers/net/fm10k/fm10k_rxtx_vec.c   |  9 +++++++++
>  7 files changed, 56 insertions(+), 1 deletion(-)
> 
> --
> 1.9.3

Acked-by: Jing Chen <jing.d.chen@intel.com>

[PATCH v2 2/3] doc: add introduction for fm10k FTAG based forwarding

[Wang Xiao W]

Add a brief introduction on FTAG, describe what's FTAG and how it works
in forwarding.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 doc/guides/nics/fm10k.rst | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst
index 4206b7f..6f61482 100644
--- a/doc/guides/nics/fm10k.rst
+++ b/doc/guides/nics/fm10k.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-    Copyright(c) 2015 Intel Corporation. All rights reserved.
+    Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
     All rights reserved.
 
     Redistribution and use in source and binary forms, with or without
@@ -34,6 +34,20 @@ FM10K Poll Mode Driver
 The FM10K poll mode driver library provides support for the Intel FM10000
 (FM10K) family of 40GbE/100GbE adapters.
 
+FTAG Based Forwarding of FM10K
+------------------------------
+
+FTAG Based Forwarding is a unique feature of FM10K. The FM10K family of NICs
+support the addition of a Fabric Tag (FTAG) to carry special information.
+The FTAG is placed at the beginning of the frame, it contains information
+such as where the packet comes from and goes, and the vlan tag. In FTAG based
+forwarding mode, the switch logic forwards packets according to glort (global
+resource tag) information, rather than the mac and vlan table. Currently this
+feature works only on PF.
+
+To enable this feature, turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD`` to y in the
+configuration file, and the application should make sure an appropriate FTAG is
+inserted for every frame on TX side.
 
 Limitations
 -----------
-- 
1.9.3

[PATCH v2 3/3] doc: update release note for fm10k FTAG support

[Wang Xiao W]

Update the release note.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 doc/guides/rel_notes/release_2_3.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..2c8b6f9 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,6 +4,7 @@ DPDK Release 2.3
 New Features
 ------------
 
+* **Added fm10k FTAG based forwarding support.**
 
 Resolved Issues
 ---------------
-- 
1.9.3

[PATCH 2/3] doc: add introduction for fm10k FTAG based forwarding

[Wang Xiao W]

Add a brief introduction on FTAG, describe what's FTAG and how it works
in forwarding.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 doc/guides/nics/fm10k.rst | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst
index 4206b7f..0f85e8c 100644
--- a/doc/guides/nics/fm10k.rst
+++ b/doc/guides/nics/fm10k.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-    Copyright(c) 2015 Intel Corporation. All rights reserved.
+    Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
     All rights reserved.
 
     Redistribution and use in source and binary forms, with or without
@@ -34,6 +34,19 @@ FM10K Poll Mode Driver
 The FM10K poll mode driver library provides support for the Intel FM10000
 (FM10K) family of 40GbE/100GbE adapters.
 
+FTAG Based Forwarding of FM10K
+------------------------------
+
+FTAG Based Forwarding is a unique feature of FM10K. The FM10K family of NICs
+support the addition of a Fabric Tag (FTAG) to carry special information.
+The FTAG is placed at the beginning of the frame, it contains information such
+as where the packet comes from and goes, and the vlan tag. In FTAG based forwarding
+mode, the switch logic forwards packets according to glort (global resource tag)
+information, rather than the mac and vlan table. Currently this feature works only
+on PF.
+
+To enable this feature, turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD`` to y in the
+configuration file.
 
 Limitations
 -----------
-- 
1.9.3

[PATCH 3/3] doc: update release note for fm10k FTAG support

[Wang Xiao W]

Update the release note.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
---
 doc/guides/rel_notes/release_2_3.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst
index 99de186..2c8b6f9 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -4,6 +4,7 @@ DPDK Release 2.3
 New Features
 ------------
 
+* **Added fm10k FTAG based forwarding support.**
 
 Resolved Issues
 ---------------
-- 
1.9.3

Re: [PATCH 3/3] doc: update release note for fm10k FTAG support

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wang Xiao W
> Sent: Monday, January 25, 2016 8:08 AM
> To: Chen, Jing D
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 3/3] doc: update release note for fm10k FTAG
> support
> 
> Update the release note.
> 
> Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>


Acked-by: John McNamara <john.mcnamara@intel.com>

Re: [PATCH 0/3] fm10k: enable FTAG based forwarding

[Liu, Yong]

Tested-by: Yong Liu <yong.liu@intel.com>

- Tested Commit: a38e5ec15e3fe615b94f3cc5edca5974dab325ab
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc version 4.8.3 20140911
- CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
- NIC: Intel Corporation Device RedrockCanyou [8086:15a4]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed

- Prerequisites command / instruction:
  Apply FM10k ftag unit test patch.
  Turn on CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD setting.
  export Port0 and Port1's GLORT ID to environment variables
    export PORT1_GLORT=0x4200
    export PORT0_GLORT=0x4000

- Case: Ftag forwarding unit test
  Description: check fm10k nic can forwarding packets based on FTAG
  Command / instruction:
    Start test application and run fm10k_ftag_autotest.
      ./x86_64-native-linuxapp-gcc/app/test -c f -n 4
      RTE>>fm10k_ftag_autotest
    Send packet to Port0 and verify packet forwarded to Port1.
      Receive 1 packets on port 0
      test for FTAG RX passed
      Send out 1 packets with FTAG on port 0
      Receive 1 packets on port 1
      test for FTAG TX passed
      Test OK

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wang Xiao W
> Sent: Monday, January 25, 2016 4:07 PM
> To: Chen, Jing D
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 0/3] fm10k: enable FTAG based forwarding
> 
> This patch set adds support for FTAG based forwarding in fm10k. This
> feature
> is a particularity of fm10k, so I add an introduction for it in fm10k.rst.
> A FTAG unit test is kept internally for feature testing, it's not included
> in the patch set due to the particularity.
> 
> Wang Xiao W (3):
>   fm10k: enable FTAG based forwarding
>   doc: add introduction for fm10k FTAG based forwarding
>   doc: update release note for fm10k FTAG support
> 
>  config/common_bsdapp                 |  1 +
>  config/common_linuxapp               |  1 +
>  doc/guides/nics/fm10k.rst            | 15 ++++++++++++++-
>  doc/guides/rel_notes/release_2_3.rst |  1 +
>  drivers/net/fm10k/fm10k_ethdev.c     |  8 ++++++++
>  drivers/net/fm10k/fm10k_rxtx.c       | 17 +++++++++++++++++
>  drivers/net/fm10k/fm10k_rxtx_vec.c   |  9 +++++++++
>  7 files changed, 51 insertions(+), 1 deletion(-)
> 
> --
> 1.9.3