On Wed, Feb 07, 2018 at 09:24:52AM +, Stokes, Ian wrote:
> > -Original Message-
> > From: Yuanhan Liu [mailto:y...@fridaylinux.org]
> > Sent: Wednesday, February 7, 2018 2:12 AM
> > To: Stokes, Ian <ian.sto...@intel.com>
> > Cc: Flavio Leitner <f
On Tue, Feb 06, 2018 at 09:34:36PM +, Stokes, Ian wrote:
> > -Original Message-
> > From: Yuanhan Liu [mailto:y...@fridaylinux.org]
> > Sent: Tuesday, February 6, 2018 9:10 AM
> > To: Flavio Leitner <f...@sysclose.org>; Stokes, Ian <ian.sto...@intel.
On Thu, Feb 01, 2018 at 01:35:15AM -0200, Flavio Leitner wrote:
> On Mon, Jan 29, 2018 at 02:59:42PM +0800, Yuanhan Liu wrote:
> > Hi,
> >
> > Here is a joint work from Mellanox and Napatech, to enable the flow hw
> > offload with the DPDK generic flow interface (rt
And mark it as experimental.
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
Documentation/howto/dpdk.rst | 17 +
NEWS | 1 +
2 files changed, 18 insertions(+)
diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index 4
could result to packet loss.
To diminish that, all those flow operations will be recorded and appended
to a list. A thread is then introduced to process this list (to do the
real flow offloading put/del operations). This could leave the datapath
as lightweight as possible.
Signed-off-by: Yuanhan Liu
For debug purpose.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
v5: - turned log to DBG level
---
lib/netdev-dpdk.c | 177 +++
.@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
---
v6: - fixed typos in commit log
- fixed a sparse warning
- used hash_int to compute the hash for mark_to_flow CMAP
- added more comments
- l
-2999) show more that
260% performance boost.
Note that though the heavy miniflow_extract is skipped, we still have
to do per packet checking, due to we have to check the tcp_flags.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
- Converted some macros to functions
- did not hardcode the max number of flow/action
- rebased on top of the latest code
Thanks.
--yliu
---
Finn Christensen (1):
netdev-dpdk: implement flow offload with rte flow
Yuanhan Liu (5):
dpif-netdev: associate flow with a mark id
dpif
On Fri, Jan 26, 2018 at 10:49:46AM +, Stokes, Ian wrote:
> > > > +static int
> > > > +mark_to_flow_disassociate(struct dp_netdev_pmd_thread *pmd,
> > > > + struct dp_netdev_flow *flow) {
> > > > +int ret = 0;
> > > > +uint32_t mark = flow->mark;
> > > > +
On Wed, Jan 24, 2018 at 05:29:45PM +, Stokes, Ian wrote:
> > Meanwhile, the mark to flow mapping becomes to 1:N mapping. That is what
>
> Is this 1:N or 1:1? I thought I spotted below that it's 1:1.
If you look further, you will also spot "1:N".
mark to mega flow is 1:1
mark to flow is 1:N
On Wed, Jan 24, 2018 at 05:29:45PM +, Stokes, Ian wrote:
> > -Original Message-
> > From: Yuanhan Liu [mailto:y...@fridaylinux.org]
> > Sent: Wednesday, December 20, 2017 2:45 PM
> > To: d...@openvswitch.org
> > Cc: Finn Christensen <f...@napatech.com
On Fri, Jan 19, 2018 at 11:03:52AM +, Stokes, Ian wrote:
> > -Original Message-
> > From: Yuanhan Liu [mailto:y...@fridaylinux.org]
> > Sent: Wednesday, January 10, 2018 3:05 AM
> > To: d...@openvswitch.org
> > Cc: Stokes, Ian <ian.sto...@in
36%PV: 38%
> 100 megaflows - 1M flowsPVP: 27%PV: 24%
> 1000 megaflows - 10M flowsPVP: 21%PV: 24%
>
> PVP for 1 megaflow offload is omitted because my VM-app imposed a bottle-neck.
>
> Regards,
> Finn
>
> -Original Message-
> From: Yuanhan Liu [mailto:y
On Mon, Jan 15, 2018 at 05:28:18PM +, Stokes, Ian wrote:
> > Hi,
> >
> > Here is a joint work from Mellanox and Napatech, to enable the flow hw
> > offload with the DPDK generic flow interface (rte_flow).
> >
> > The basic idea is to associate the flow with a mark id (a unit32_t
> > number).
so what I have been thinking of. It's also easier to
make decisions when we are at the step of doing real extension (say, adding
the full offload).
--yliu
> > -Original Message-
> > From: Yuanhan Liu [mailto:y...@fridaylinux.org]
> > Sent: Monday, December 25, 2017
/2017-October/339496.html
Cc: Loftus Ciara <ciara.lof...@intel.com>
Cc: Thomas Monjalon <tho...@monjalon.net>
Cc: Kevin Traynor <ktray...@redhat.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
v3: - reuse eth helper functions from OVS, suggested by Ilya Maximets
v2:
On Tue, Jan 09, 2018 at 02:14:22PM +0300, Ilya Maximets wrote:
> > +static dpdk_port_t
> > +netdev_dpdk_get_port_by_mac(const char *mac_str)
> > +{
> > +int i;
> > +struct ether_addr mac;
> > +struct ether_addr port_mac;
> > +
> > +if (netdev_dpdk_str_to_ether(mac_str, ) != 0) {
>
/2017-October/339496.html
Cc: Loftus Ciara <ciara.lof...@intel.com>
Cc: Thomas Monjalon <tho...@monjalon.net>
Cc: Kevin Traynor <ktray...@redhat.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
v2: - added doc for the new devags syntax
- added error
On Mon, Jan 08, 2018 at 01:10:10PM +, Stokes, Ian wrote:
> Hi Yuanhan,
>
> Thanks for working on this, I've done some testing with ani40e device and a
> review of the current patch, please find comments below.
>
> > On 12/20/2017 04:03 PM, Yuanhan Liu wrote:
> >
ping ...
On Thu, Dec 21, 2017 at 12:03:36AM +0800, Yuanhan Liu wrote:
> Some NICs have only one PCI address associated with multiple ports. This
> patch extends the dpdk-devargs option's format to cater for such devices.
>
> To achieve that, this patch uses a new syntax that wil
From: Finn Christensen [mailto:f...@napatech.com]
> > Sent: Friday, December 22, 2017 11:29 AM
> > To: Yuanhan Liu <y...@fridaylinux.org>; d...@openvswitch.org
> > Cc: Darrell Ball <db...@vmware.com>; Chandran, Sugesh
> > <sugesh.chand...@intel.com>; Simon Hor
egaflows - 1M flowsPVP: 27%PV: 24%
> 1000 megaflows - 10M flowsPVP: 21%PV: 24%
>
> PVP for 1 megaflow offload is omitted because my VM-app imposed a bottle-neck.
>
> Regards,
> Finn
>
> -Original Message-
> From: Yuanhan Liu [mailto:y...@fridaylinux.org
/2017-October/339496.html
Cc: Loftus Ciara <ciara.lof...@intel.com>
Cc: Thomas Monjalon <tho...@monjalon.net>
Cc: Kevin Traynor <ktray...@redhat.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
lib/netdev-dpdk.c | 77 ---
could result to packet loss.
To diminish that, all those flow operations will be recorded and appended
to a list. A thread is then introduced to process this list (to do the
real flow offloading put/del operations). This could leave the datapath
as lightweight as possible.
Signed-off-by: Yuanhan Liu
For debug purpose.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
v5: - turned log to DBG level
---
lib/netdev-dpdk.c | 177 +++
hoosen.
For any unsupported flows, such as MPLS, -1 is returned, meaning the
flow offload is failed and then skipped.
Co-authored-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.or
-2999) show more that
260% performance boost.
Note that though the heavy miniflow_extract is skipped, we still have
to do per packet checking, due to we have to check the tcp_flags.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
y masking all the bytes from match->flow with match->wc. It works
well so far, but I have a feeling that is not the best way.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen &
On Tue, Dec 12, 2017 at 02:47:37PM +, Finn Christensen wrote:
> +struct flow_mark {
> +struct cmap megaflow_to_mark;
> +struct cmap mark_to_flow;
> +struct id_pool *pool;
> +struct ovs_mutex mutex;
>
> [Finn] Is this mutex needed? - the structure seems to
On Fri, Nov 24, 2017 at 05:59:09PM +0800, Chen Hailin wrote:
> Hi Aaron Conole && Jianfeng,
>
> The stp could not work in ovs-dpdk vhostuser.
> Because the attached vhost device doesn't have MAC address.
>
> Now we have two ways to solve this problem.
> 1. The vhost learns MAC address from
The log level will be set to DBG when this patchset is close to
being merged.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
---
lib/n
could result to packet loss.
To diminish that, all those flow operations will be recorded and appended
to a list. A thread is then introduced to process this list (to do the
real flow offloading put/del operations). This could leave the datapath
as lightweight as possible.
Signed-off-by: Yuanhan Liu
hoosen.
For any unsupported flows, such as MPLS, -1 is returned, meaning the
flow offload is failed and then skipped.
Co-authored-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.or
-2999) show more that
260% performance boost.
Note that though the heavy miniflow_extract is skipped, we still have
to do per packet checking, due to we have to check the tcp_flags.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
y masking all the bytes from match->flow with match->wc. It works
well so far, but I have a feeling that is not the best way.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f..
on top of the latest code
Thanks.
--yliu
---
Finn Christensen (1):
netdev-dpdk: implement flow offload with rte flow
Yuanhan Liu (4):
dpif-netdev: associate flow with a mark id
dpif-netdev: retrieve flow directly from the flow mark
netdev-dpdk: add debug for rte flow patterns
dpif
On Tue, Oct 10, 2017 at 06:26:51PM +0530, devendra rawat wrote:
> > Hi Everyone,
> >
> > Anything finalized for sorting out this issue, do you need any more
> > information regarding this issue ?
>
> Hi,
>
> I put together a very rough RFC that aims to work-around the
On Tue, Oct 31, 2017 at 02:19:20PM -0700, Ben Pfaff wrote:
> I see that this series appears to have stalled. Should we expect a new
> version sometime soon? Do you need more reviews on the current version?
My bad. As I have stated in another email, I meant to send v4 earlier, but
I found a bug.
On Wed, Sep 27, 2017 at 10:09:20AM +0800, Yuanhan Liu wrote:
> On Wed, Sep 27, 2017 at 09:24:54AM +0800, Yuanhan Liu wrote:
> > > The support needed would be in some drivers and seems reasonably doable.
> > > Moreover, this was discussed in the last dpdk me
On Wed, Sep 27, 2017 at 09:12:49AM +, Finn Christensen wrote:
>
> [Darrell] It looks fine; of course, if we could drop dependencies on cap
> probe, it would be ideal (.
>
>
> [Finn]
> From a Napatech point of view, we would definitely want to use the
> RTE_FLOW_ACTION_TYPE_RSS if it
On Wed, Sep 27, 2017 at 03:13:33AM +, Darrell Ball wrote:
>
>
> On 9/26/17, 6:25 PM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
>
> On Tue, Sep 26, 2017 at 09:58:16PM +, Darrell Ball wrote:
> > The second major change is there is
On Wed, Sep 27, 2017 at 09:24:54AM +0800, Yuanhan Liu wrote:
> > The support needed would be in some drivers and seems reasonably doable.
> > Moreover, this was discussed in the last dpdk meeting and the support was
> > indicated as existing?, although I only verified th
On Tue, Sep 26, 2017 at 09:58:16PM +, Darrell Ball wrote:
> The second major change is there is a thread introduced to do the real
> flow offload. This is for diminishing the overhead by hw flow offload
> installation/deletion at data path. See patch 9 for more detailed info.
>
>
could result to packet loss.
To diminish that, all those flow operations will be recorded and appended
to a list. A thread is then introduced to process this list (to do the
real flow offloading put/del operations). This could leave the datapath
as lightweight as possible.
Signed-off-by: Yuanhan Liu
The log level will be set to DBG when this patchset is close to
being merged.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
---
lib/n
Inovke netdev class '->flow_del' method on flow deletion. The dpdk netdev
implementation will then remove the rte flow associated with the ufid.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn
, some Intel's NIC (say XL710) needs the QUEUE action set
before the MARK action.
Co-authored-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
v3: - retry when 2 specific errors are
e flow content.
Here we record the rx queue while recieving the pkts to solve above issue.
Co-authored-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Shachar Beiser <shacha...@mellanox.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
lib/dp-packet.h | 1 +
nsupported flows, such as MPLS, -1 is returned, meaning the
flow offload is failed and then skipped.
Co-authored-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
v3: - fix duplicate (an
put method) to setup
the hw flow. The flow_put implementation then is supposed to create a
flow with MARK action for current stage, which is, only partial offload
is supported.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Sign
to we have to check
the tcp_flags.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
---
v3: - replace CMAP with array, which futhure improves the
performa
---
Finn Christensen (2):
netdev-dpdk: implement flow put with rte flow
netdev-dpdk: retry with queue action
Shachar Beiser (1):
dpif-netdev: record rx queue id for the upcall
Yuanhan Liu (6):
dpif-netdev: associate flow with a mark id
dpif-netdev: retrieve flow directly from the flow mark
On Thu, Sep 21, 2017 at 09:00:10AM +, Darrell Ball wrote:
>
>
> On 9/21/17, 1:54 AM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
>
> On Thu, Sep 21, 2017 at 08:04:45AM +, Darrell Ball wrote:
> > Hi Yuanhan/Finn
> >
> >
---Original Message-
> > From: Darrell Ball [mailto:db...@vmware.com]
> > Sent: Thursday, September 14, 2017 6:46 PM
> > To: Chandran, Sugesh <sugesh.chand...@intel.com>; Yuanhan Liu
> > <y...@fridaylinux.org>
> > Cc: Finn Christense
On Thu, Sep 21, 2017 at 07:55:53AM +, Darrell Ball wrote:
> Hi Yuanhan
>
> We discussed the RTE_FLOW_ACTION_TYPE_RSS action, in the dpdk meeting.
> There is related discussion and details in this thread.
> It seems the RTE_FLOW_ACTION_TYPE_RSS action can be supported by the drivers.
> If this
On Fri, Sep 15, 2017 at 06:30:06PM +, Darrell Ball wrote:
> That was my first reaction to remove such blind re-try. It could have
> been a good option if all the PMD driver report the error consistenly.
>
> And unfortunately, it's not true. For example, for MARK without QUEUE
On Fri, Sep 15, 2017 at 07:00:40PM +, Darrell Ball wrote:
> > In this case, we have what seems like a clear distinction b/w Napatech
> which does not need the
> > queue action workaround and everything else, which does.
> > Besides the non-Napatech behavior, which is worrisome,
On Wed, Sep 13, 2017 at 11:52:34AM +0200, Simon Horman wrote:
> > > > +/* Add ufid to dpdk_flow mapping */
> > > > +static inline void
> > > > +add_ufid_dpdk_flow_mapping(const ovs_u128 *ufid, struct rte_flow
> > > *rte_flow)
> > > > +{
> > > > +size_t hash =
On Thu, Sep 14, 2017 at 11:42:38PM +, Darrell Ball wrote:
>
>
> On 9/5/17, 2:23 AM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
>
> This patch associate a flow with a mark id (a uint32_t number) by CMAP.
>
> It re-uses the flow API (
On Tue, Sep 12, 2017 at 08:36:19AM +, Darrell Ball wrote:
>
> On 9/10/17, 11:14 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yuanhan
> Liu" <ovs-dev-boun...@openvswitch.org on behalf of y...@fridaylinux.org>
> wrote:
>
> On Fri, Sep 08, 2017 at 06
"ovs-dev-boun...@openvswitch.org on behalf of
> Yuanhan Liu" <ovs-dev-boun...@openvswitch.org on behalf of
> y...@fridaylinux.org> wrote:
> >
> > On Fri, Sep 08, 2017 at 06:48:50PM +0200, Simon Horman wrote:
> > > On Tue, Sep 05,
On Wed, Sep 13, 2017 at 03:04:05AM +, Darrell Ball wrote:
> [Sugesh] Yes, you are right.
> >
> > > If there is a
> > > functionality issue to configure the MARK action properly, it has to
> > > be fixed in DPDK than doing a workaround in OVS.
> >
> > Again, can't
Message-
> From: ovs-dev-boun...@openvswitch.org
> [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Yuanhan Liu
> Sent: 11. september 2017 09:55
> To: Chandran, Sugesh <sugesh.chand...@intel.com>
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [P
On Wed, Sep 13, 2017 at 05:20:58AM +, Darrell Ball wrote:
>
>
> On 9/5/17, 2:23 AM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
>
> So that we could skip the heavy emc processing, notably, the
> miniflow_extract function. A simple PHY-PHY
On Wed, Sep 13, 2017 at 05:18:03AM +, Darrell Ball wrote:
> +/* IP v4 */
> +uint8_t proto = 0;
> +struct rte_flow_item_ipv4 ipv4_spec;
> +struct rte_flow_item_ipv4 ipv4_mask;
> +memset(_mask, 0, sizeof(ipv4_mask));
> +if
On Wed, Sep 13, 2017 at 11:45:30AM +0200, Simon Horman wrote:
> > > > +rte_memcpy(_spec.dst, >flow.dl_dst,
> > sizeof(eth_spec.dst));
> > > > +rte_memcpy(_spec.src, >flow.dl_src,
> > sizeof(eth_spec.src));
> > > > +eth_spec.type = match->flow.dl_type;
> >
On Mon, Sep 11, 2017 at 10:00:06AM +, Chandran, Sugesh wrote:
> > > In our implementation we have a feature discovery at the OVS init. It will
> > also populate the OVSDB to expose the device capability to higher
> > management layers. The new table introduced in OVSDB is like below.
> >
> >
On Mon, Sep 11, 2017 at 10:04:21AM +, Chandran, Sugesh wrote:
>
>
> Regards
> _Sugesh
>
>
> > -Original Message-----
> > From: Yuanhan Liu [mailto:y...@fridaylinux.org]
> > Sent: Monday, September 11, 2017 10:58 AM
> > To: Chandran, Su
On Mon, Sep 11, 2017 at 09:49:52AM +, Chandran, Sugesh wrote:
> > > > For the DPDK flow offload, which basically just binds a MARK action
> > > > to a flow, the MARK is required to be used together with a QUEUE
> > > > action for the most NICs I'm aware of. The QUEUE action then needs a
> > >
On Sun, Sep 10, 2017 at 04:32:19PM +, Chandran, Sugesh wrote:
> As mentioned earlier in the cover letter we also have a similar
> implementation to do the flow translate.
> I feel its good to make bit more modular for this translation. The reason
> being its easy to extend and add more
On Sun, Sep 10, 2017 at 04:40:10PM +, Chandran, Sugesh wrote:
>
>
> Regards
> _Sugesh
>
>
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Yuanhan Liu
> > Sent: Tue
then is supposed to create a flow
> > with MARK action.
> >
> > Co-authored-by: Finn Christensen <f...@napatech.com>
> > Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
> > Signed-off-by: Fin
On Mon, Sep 11, 2017 at 07:42:19AM +, Chandran, Sugesh wrote:
>
>
> Regards
> _Sugesh
>
>
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Yuanhan Liu
> > Sent: Tue
On Mon, Sep 11, 2017 at 07:42:57AM +, Chandran, Sugesh wrote:
>
>
> Regards
> _Sugesh
>
>
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Yuanhan Liu
> > Sent: Tue
On Sun, Sep 10, 2017 at 04:15:42PM +, Chandran, Sugesh wrote:
> > atomic_read_relaxed(>dp->emc_insert_min, _min);
> >
> > DP_PACKET_BATCH_REFILL_FOR_EACH (i, size, packet, packets_) {
> > struct dp_netdev_flow *flow;
> > +uint32_t flow_mark;
> >
> > if
l aspects.
> I had some comments related to coding standards for V2, but I’ll wait for you
> to respond
> to Simon’s comments before adding my own other comments, in order to avoid
> confusion.
>
> Thanks Darrell
>
>
> On 9/5/17, 2:22 AM, "Yuan
On Fri, Sep 08, 2017 at 06:48:16PM +0200, Simon Horman wrote:
> On Tue, Sep 05, 2017 at 05:23:01PM +0800, Yuanhan Liu wrote:
> > From: Finn Christensen <f...@napatech.com>
> >
> > The Intel i40e PMD driver requires the fdir mode set to
> > RTE_FDIR_MODE_PERFECT, o
On Fri, Sep 08, 2017 at 06:48:50PM +0200, Simon Horman wrote:
> On Tue, Sep 05, 2017 at 05:22:59PM +0800, Yuanhan Liu wrote:
> > From: Finn Christensen <f...@napatech.com>
> >
> > AFAIK, most (if not all) NICs (including Mellanox and Intel) do not
> > support a
On Fri, Sep 08, 2017 at 06:47:55PM +0200, Simon Horman wrote:
> On Tue, Sep 05, 2017 at 05:22:57PM +0800, Yuanhan Liu wrote:
> > From: Finn Christensen <f...@napatech.com>
> >
> > The basic yet the major part of this patch is to translate the "match"
> >
On Fri, Sep 08, 2017 at 05:48:36PM +, Darrell Ball wrote:
>
> > +static inline void
> > +del_ufid_dpdk_flow_mapping(const ovs_u128 *ufid)
> > +{
> > +struct ufid_dpdk_flow_data *data;
> > +
> > +data = find_ufid_dpdk_flow_mapping(ufid);
> > +if (data) {
On Fri, Sep 08, 2017 at 05:38:07PM +, Darrell Ball wrote:
> > +static inline bool
> > +dp_packet_has_flow_mark(struct dp_packet *p OVS_UNUSED,
> > +uint32_t *mark OVS_UNUSED)
> > +{
> > +#ifdef DPDK_NETDEV
> > +if (p->mbuf.ol_flags &
On Fri, Sep 08, 2017 at 06:44:16PM +0200, Simon Horman wrote:
> On Tue, Sep 05, 2017 at 05:22:54PM +0800, Yuanhan Liu wrote:
> > This patch associate a flow with a mark id (a uint32_t number) by CMAP.
> >
> > It re-uses the flow API (more precisely, the ->flow_put method)
On Thu, Sep 07, 2017 at 06:52:49PM +, Patil, Harish wrote:
> >Hi all,
> >
> >Can you please confirm that you are supporting offloading of both the EMC
> >flows and DPCLs (megaflows) here, i.e. OVS would skip hash table lookups
> >in both the cases if UFID is provided in the MBUF. Assuming that
From: Finn Christensen <f...@napatech.com>
The Intel i40e PMD driver requires the fdir mode set to
RTE_FDIR_MODE_PERFECT, otherwise, the flow creation would
be failed.
Co-authored-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
Sign
Inovke netdev class '->flow_del' method on flow deletion. The dpdk netdev
implementation will then remove the rte flow associated with the ufid.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn
, some Intel's NIC (say XL710) needs the QUEUE action set
before the MARK action.
Co-authored-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
v2: - workarounded the queue action iss
e flow content.
Here we record the rx queue while recieving the pkts to solve above issue.
Co-authored-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Shachar Beiser <shacha...@mellanox.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
lib/dp-packet.h | 1 +
nsupported flows, such as MPLS, -1 is returned, meaning the
flow offload is failed and then skipped.
Co-authored-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
---
v2: - convert some macros
ot;, which is a trick to workaround
the temp "functiond defined but not used" warnings.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napate
.
Co-authored-by: Finn Christensen <f...@napatech.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
---
v2: update tcp_flags, which also fixes the build warnings
---
lib/dp-packet.h | 13 ++
lib/
ch.com>
Signed-off-by: Yuanhan Liu <y...@fridaylinux.org>
Signed-off-by: Finn Christensen <f...@napatech.com>
---
lib/dpif-netdev.c | 85 +++
lib/netdev.h | 6
2 files changed, 91 insertions(+)
diff --git a/lib/dpif-netdev.
netdev-dpdk: retry with queue action
netdev-dpdk: set FDIR config
Shachar Beiser (1):
dpif-netdev: record rx queue id for the upcall
Yuanhan Liu (4):
dpif-netdev: associate flow with a mark id
dpif-netdev: retrieve flow directly from the flow mark
netdev-dpdk: convert ufid to dpdk flow
On Fri, Sep 01, 2017 at 10:35:51PM +, Darrell Ball wrote:
>
>
> On 8/31/17, 3:13 AM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
>
> On Wed, Aug 30, 2017 at 07:28:01PM +, Darrell Ball wrote:
> >
> > [Finn]
> &g
On Fri, Sep 01, 2017 at 10:38:37PM +, Darrell Ball wrote:
>
>
> On 8/29/17, 7:33 PM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
>
> On Wed, Aug 30, 2017 at 02:02:23AM +, Darrell Ball wrote:
> >
> > >
On Wed, Aug 30, 2017 at 07:39:35PM +, Darrell Ball wrote:
> > > Note that it's disabled by default, which can be enabled
> by:
> > >
> > > $ ovs-vsctl set Open_vSwitch .
> other_config:hw-offload=true
> > >
> > > Maybe per
On Wed, Aug 30, 2017 at 07:28:01PM +, Darrell Ball wrote:
>
> [Finn]
>
> I think we should not further intermix the rxqs distributed to different
> pmd's, other than initially configured, when setting up hw-offload. If we
> make a round-robin distribution of the rxqs, a
run
>
> ./utilities/checkpatch.py
>
> before the next iteration
Sure.
--yliu
>
> Thanks Darrell
>
>
> On 8/22/17, 11:24 PM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
>
> Hi,
>
> Here is a jo
On Wed, Aug 30, 2017 at 02:02:23AM +, Darrell Ball wrote:
>
> > +#define MAX_RTE_FLOW_ITEMS 100
> > +#define MAX_RTE_FLOW_ACTIONS100
> >
> > I guess these are temporary
>
> Yes, the hardcoded number is really hacky.
>
> > Do we need
On Wed, Aug 30, 2017 at 01:55:28AM +, Darrell Ball wrote:
>
>
> On 8/29/17, 5:09 AM, "Yuanhan Liu" <y...@fridaylinux.org> wrote:
>
> On Tue, Aug 29, 2017 at 07:14:48AM +, Darrell Ball wrote:
> > Hi
> >
> >
1 - 100 of 114 matches
Mail list logo
