On 10/31/2019 5:53 PM, Ferruh Yigit wrote:
> On 10/8/2019 3:23 PM, Yigit, Ferruh wrote:
>> On 7/30/2019 4:59 PM, Thomas Monjalon wrote:
>>> Since the concept of representors was introduced,
>>> we do not need any specific API for VF ports.
>>> Any VF port should be able to be configured through
>>>
On 10/8/2019 3:23 PM, Yigit, Ferruh wrote:
> On 7/30/2019 4:59 PM, Thomas Monjalon wrote:
>> Since the concept of representors was introduced,
>> we do not need any specific API for VF ports.
>> Any VF port should be able to be configured through
>> its representor port in a more generic fashion.
>
On 7/30/2019 4:59 PM, Thomas Monjalon wrote:
> Since the concept of representors was introduced,
> we do not need any specific API for VF ports.
> Any VF port should be able to be configured through
> its representor port in a more generic fashion.
I think we need a confirmation that functionality
On Wed, Jul 31, 2019 at 2:36 AM Andrew Rybchenko
wrote:
> On 7/30/19 6:59 PM, Thomas Monjalon wrote:
> > Since the concept of representors was introduced,
> > we do not need any specific API for VF ports.
> > Any VF port should be able to be configured through
> > its representor port in a more g
On 7/30/19 6:59 PM, Thomas Monjalon wrote:
Since the concept of representors was introduced,
we do not need any specific API for VF ports.
Any VF port should be able to be configured through
its representor port in a more generic fashion.
Signed-off-by: Thomas Monjalon
Acked-by: Andrew Rybche
Since the concept of representors was introduced,
we do not need any specific API for VF ports.
Any VF port should be able to be configured through
its representor port in a more generic fashion.
Signed-off-by: Thomas Monjalon
---
drivers/net/bnxt/rte_pmd_bnxt.h | 15 ++-
drivers/n
6 matches
Mail list logo