Declan,
In all previous series I explained my objection for using the broker
framework for holding the VF rep port.
You guys just waved it away (and sent a new series) instead of really
giving a clear reason why they are required.
I think Yuanhan's suggestion gets ride of the broker model in a cl
On Wed, Dec 27, 2017 at 11:40 AM, Mohammad Abdul Awal
wrote:
> On 22/12/2017 22:33, Alex Rosenbaum wrote:
>> On Fri, Dec 22, 2017 at 4:31 PM, Mohammad Abdul Awal
>>> On 21/12/2017 14:51, Alex Rosenbaum wrote:
> By hotplug I did not mean HW hotplug, rather I meant the softw
On Tue, Dec 26, 2017 at 5:28 AM, Zhang, Qi Z wrote:
>> On Fri, Dec 22, 2017 at 11:03 AM, Zhang, Qi Z wrote:
>> >> On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote:
>> >> > Add new APIs to support flow timeout, application is able to 1.
>> >> > Setup the time duration of a flow, the flow is expect
On Fri, Dec 22, 2017 at 4:31 PM, Mohammad Abdul Awal
wrote:
> On 21/12/2017 14:51, Alex Rosenbaum wrote:
>> As described in the links Alejandro referenced earlier, each of the
>> switch ports should be a real PMD, and switch operations should be
>> applied on these PMD ports.
On Fri, Dec 22, 2017 at 11:03 AM, Zhang, Qi Z wrote:
>> On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote:
>> > Add new APIs to support flow timeout, application is able to 1. Setup
>> > the time duration of a flow, the flow is expected to be deleted
>> > automatically when timeout.
>>
>> Can you e
+Adrien
On Fri, Dec 22, 2017 at 10:20 AM, Zhang, Qi Z wrote:
>> On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote:
>> > Add action RTE_FLOW_ACTION_TYPE_SWITCH_PORT, it can be used to
>> > redirect
>> A verbs would be better suited for an ACTION_TYPE. while ".._TYPE_PORT" is
>> a nous.
>> Probably
Declan, Mohammad,
The submission [1] of steering action between switch ports clearly
requires a switch model in DPDK.
The Port Representor based on a virtual PMD broker on NIC ops
(rte_dev_ops) does not provide the required functionality. Using NIC
terminology and not Switch API's will lead to a d
On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote:
> Add new APIs to support flow timeout, application is able to
> 1. Setup the time duration of a flow, the flow is expected to be deleted
> automatically when timeout.
Can you explain how the application (OVS) is expected to use this API?
It will h
On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote:
> This patch extend rte_flow API.
> The purpose is to provide comfortable programming interface for virtual switch
> software (such as OVS) to take advantage of incoming device's vSwitch
> acceleration
> capability when using DPDK as data plane.
>
On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote:
> Add action RTE_FLOW_ACTION_TYPE_SWITCH_PORT, it can be used to redirect
I guess the word "SWITCH" should be remove from commit message. you
don't use it later in the patch.
>
> +Action: ``PORT``
> +
> +
> +Redirect packets to an
Mohammad,
I did not see a v2 change log. did I miss it? please send.
I don't understand who this v2 addresses the comments by Alejandro Lucero
from netronome [1].
These are critical points which your proposal does not handle. It is
related to the switch_domain member exposed here.
thanks,
Alex
please excuse me if I missed out of the previous conversation and
asking these questions again...
Why create a new driver instead of improving the existing KNI driver?
Can you share a table of the differences between the two driver /
approaches [KNI vs KCP]?
Why do you want to remove features lik
12 matches
Mail list logo
