On 27/12/2017 15:50, Alex Rosenbaum wrote:
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
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 software hotplug of
> port rep
On 22/12/2017 22:33, Alex Rosenbaum wrote:
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
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.
>> This includes the
Hi ALex,
On 21/12/2017 14:51, Alex Rosenbaum wrote:
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. Usi
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, Sep 7, 2017 at 2:13 PM, Declan Doherty
wrote:
> On 07/09/2017 11:01 AM, Alejandro Lucero wrote:
>
>> I understand this is the representor idea suiting Intel cards but it does
>> not cover other possibilities.
>>
>> At least, Netronome and Mellanox require a representor not just for
>> con
On 07/09/2017 11:01 AM, Alejandro Lucero wrote:
I understand this is the representor idea suiting Intel cards but it does
not cover other possibilities.
At least, Netronome and Mellanox require a representor not just for
controlling a VF, but also for sending and receiving packets through the
re
I understand this is the representor idea suiting Intel cards but it does
not cover other possibilities.
At least, Netronome and Mellanox require a representor not just for
controlling a VF, but also for sending and receiving packets through the
representor PMD.
I sent an abstract for a presentat
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
Signed-off-by: Declan Doherty
---
This RFC introduces a port representor based model for the control, management
and monitoring of SR-IOV virtual function (VF) devices for control plane
applications which have bound the devices physic
10 matches
Mail list logo
