diff mbox

[dpdk-dev,06/13] null: fake PMD capabilities

Message ID d393aff59d03e46fc878f874e30ba53216efb396.1481590851.git.mirq-linux@rere.qmqm.pl (mailing list archive)
State Superseded, archived
Headers

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/Intel compilation success Compilation OK

Commit Message

Michał Mirosław Dec. 13, 2016, 1:08 a.m. UTC 
  From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>

Thanks to that change we can use Null PMD for testing purposes.

Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
---
 drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

Comments

Ananyev, Konstantin Dec. 13, 2016, 10:48 a.m. UTC | #1 
> -----Original Message-----

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw

> Sent: Tuesday, December 13, 2016 1:08 AM

> To: dev@dpdk.org

> Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities

> 

> From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>

> 

> Thanks to that change we can use Null PMD for testing purposes.

> 

> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>

> ---

>  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-

>  1 file changed, 12 insertions(+), 1 deletion(-)

> 

> diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c

> index 836d982..f32ba2a 100644

> --- a/drivers/net/null/rte_eth_null.c

> +++ b/drivers/net/null/rte_eth_null.c

> @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,

>  	return 0;

>  }

> 

> +static void

> +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }

> +

> 

>  static void

>  eth_dev_info(struct rte_eth_dev *dev,

> @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,

>  	dev_info->pci_dev = NULL;

>  	dev_info->reta_size = internals->reta_size;

>  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;

> +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in

> /dev/null */

> +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;

> +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;


Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
Same question for RX.
Konstantin

>  }

> 

>  static void

> @@ -477,7 +483,12 @@ static const struct eth_dev_ops ops = {

>  	.reta_update = eth_rss_reta_update,

>  	.reta_query = eth_rss_reta_query,

>  	.rss_hash_update = eth_rss_hash_update,

> -	.rss_hash_conf_get = eth_rss_hash_conf_get

> +	.rss_hash_conf_get = eth_rss_hash_conf_get,

> +	/* Fake our capabilities */

> +	.promiscuous_enable   = eth_dev_void_ok,

> +	.promiscuous_disable  = eth_dev_void_ok,

> +	.allmulticast_enable  = eth_dev_void_ok,

> +	.allmulticast_disable = eth_dev_void_ok

>  };

> 

>  int

> --

> 2.10.2
Michał Mirosław Dec. 13, 2016, 2:26 p.m. UTC | #2 
On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > Sent: Tuesday, December 13, 2016 1:08 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > 
> > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > 
> > Thanks to that change we can use Null PMD for testing purposes.
> > 
> > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > ---
> >  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > index 836d982..f32ba2a 100644
> > --- a/drivers/net/null/rte_eth_null.c
> > +++ b/drivers/net/null/rte_eth_null.c
> > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> >  	return 0;
> >  }
> > 
> > +static void
> > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > +
> > 
> >  static void
> >  eth_dev_info(struct rte_eth_dev *dev,
> > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
> >  	dev_info->pci_dev = NULL;
> >  	dev_info->reta_size = internals->reta_size;
> >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in
> > /dev/null */
> > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> 
> Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
> Same question for RX.

You could imagine, that before dropping the packet you insert the tag
and calculate the checksum. The observed effect will be the same.

On RX this always indicates lack of VLAN tag. So whether the offload
is enabled or not it doesn't matter.

Best Regards,
Michał Mirosław
Ananyev, Konstantin Dec. 13, 2016, 2:37 p.m. UTC | #3 
> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 2:27 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> 
> On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > >
> > > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > >
> > > Thanks to that change we can use Null PMD for testing purposes.
> > >
> > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > ---
> > >  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
> > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > > index 836d982..f32ba2a 100644
> > > --- a/drivers/net/null/rte_eth_null.c
> > > +++ b/drivers/net/null/rte_eth_null.c
> > > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> > >  	return 0;
> > >  }
> > >
> > > +static void
> > > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > > +
> > >
> > >  static void
> > >  eth_dev_info(struct rte_eth_dev *dev,
> > > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
> > >  	dev_info->pci_dev = NULL;
> > >  	dev_info->reta_size = internals->reta_size;
> > >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > > +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in
> > > /dev/null */
> > > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> >
> > Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
> > Same question for RX.
> 
> You could imagine, that before dropping the packet you insert the tag
> and calculate the checksum. The observed effect will be the same.
> 
> On RX this always indicates lack of VLAN tag. So whether the offload
> is enabled or not it doesn't matter.

Of course user can imagine whatever he likes, but what the point to advertise these capabilities,
when the PMD clearly doesn't have them?
Again, why these particular ones?
Konstantin

> 
> Best Regards,
> Michał Mirosław
Michał Mirosław Dec. 13, 2016, 2:57 p.m. UTC | #4 
On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote:
> 
> 
> > -----Original Message-----
> > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > Sent: Tuesday, December 13, 2016 2:27 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > 
> > On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > > To: dev@dpdk.org
> > > > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > > >
> > > > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > > >
> > > > Thanks to that change we can use Null PMD for testing purposes.
> > > >
> > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > ---
> > > >  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
> > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > > > index 836d982..f32ba2a 100644
> > > > --- a/drivers/net/null/rte_eth_null.c
> > > > +++ b/drivers/net/null/rte_eth_null.c
> > > > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> > > >  	return 0;
> > > >  }
> > > >
> > > > +static void
> > > > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > > > +
> > > >
> > > >  static void
> > > >  eth_dev_info(struct rte_eth_dev *dev,
> > > > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
> > > >  	dev_info->pci_dev = NULL;
> > > >  	dev_info->reta_size = internals->reta_size;
> > > >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > > > +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in
> > > > /dev/null */
> > > > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > > > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> > >
> > > Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
> > > Same question for RX.
> > 
> > You could imagine, that before dropping the packet you insert the tag
> > and calculate the checksum. The observed effect will be the same.
> > 
> > On RX this always indicates lack of VLAN tag. So whether the offload
> > is enabled or not it doesn't matter.
> 
> Of course user can imagine whatever he likes, but what the point to advertise these capabilities,
> when the PMD clearly doesn't have them?
> Again, why these particular ones?

Hmm. I guess we can expand the set. Those were the ones we actually use
(depend on) for testing our code.

This allows to use null PMD for testing in place of real network interface
with those offloads. This patch is to keep users from having to place if's
around their code just to support test scenarios with null PMD.

Best Regards,
Michał Mirosław
Ananyev, Konstantin Dec. 13, 2016, 5:12 p.m. UTC | #5 
> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 2:58 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> 
> On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > Sent: Tuesday, December 13, 2016 2:27 PM
> > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > >
> > > On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > > > To: dev@dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > > > >
> > > > > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > > > >
> > > > > Thanks to that change we can use Null PMD for testing purposes.
> > > > >
> > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > ---
> > > > >  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
> > > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > > > > index 836d982..f32ba2a 100644
> > > > > --- a/drivers/net/null/rte_eth_null.c
> > > > > +++ b/drivers/net/null/rte_eth_null.c
> > > > > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> > > > >  	return 0;
> > > > >  }
> > > > >
> > > > > +static void
> > > > > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > > > > +
> > > > >
> > > > >  static void
> > > > >  eth_dev_info(struct rte_eth_dev *dev,
> > > > > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
> > > > >  	dev_info->pci_dev = NULL;
> > > > >  	dev_info->reta_size = internals->reta_size;
> > > > >  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > > > > +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking
> packets in
> > > > > /dev/null */
> > > > > +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > > > > +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> > > >
> > > > Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
> > > > Same question for RX.
> > >
> > > You could imagine, that before dropping the packet you insert the tag
> > > and calculate the checksum. The observed effect will be the same.
> > >
> > > On RX this always indicates lack of VLAN tag. So whether the offload
> > > is enabled or not it doesn't matter.
> >
> > Of course user can imagine whatever he likes, but what the point to advertise these capabilities,
> > when the PMD clearly doesn't have them?
> > Again, why these particular ones?
> 
> Hmm. I guess we can expand the set. Those were the ones we actually use
> (depend on) for testing our code.
> 
> This allows to use null PMD for testing in place of real network interface
> with those offloads. 

As I can see on TX null pmd would just drop the packets, right?
So  the only thing you might check, as I understand, did upper layer code
setup ol_flags  and other mbuf fields properly depending on advertised capabilities
(probably via sme special tx_callback installed  or so).
Is that correct? 
That's ok, I  suppose, but if tomorrow you (or someone else) would like to test
with different RX/TX offloads?   
Shouldn't be advertised offload capabilities be configurable at device creation/attach time
somehow?
Or at least just advertise all possible ones then?

Konstantin

>This patch is to keep users from having to place if's
> around their code just to support test scenarios with null PMD.
> 
> Best Regards,
> Michał Mirosław
Ferruh Yigit Dec. 13, 2016, 5:31 p.m. UTC | #6 
On 12/13/2016 5:12 PM, Ananyev, Konstantin wrote:
> 
> 
>> -----Original Message-----
>> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
>> Sent: Tuesday, December 13, 2016 2:58 PM
>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
>>
>> On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
>>>> Sent: Tuesday, December 13, 2016 2:27 PM
>>>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
>>>> Cc: dev@dpdk.org
>>>> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
>>>>
>>>> On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
>>>>>> -----Original Message-----
>>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
>>>>>> Sent: Tuesday, December 13, 2016 1:08 AM
>>>>>> To: dev@dpdk.org
>>>>>> Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
>>>>>>
>>>>>> From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
>>>>>>
>>>>>> Thanks to that change we can use Null PMD for testing purposes.
>>>>>>
>>>>>> Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
>>>>>> ---
>>>>>>  drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
>>>>>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
>>>>>> index 836d982..f32ba2a 100644
>>>>>> --- a/drivers/net/null/rte_eth_null.c
>>>>>> +++ b/drivers/net/null/rte_eth_null.c
>>>>>> @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
>>>>>>  	return 0;
>>>>>>  }
>>>>>>
>>>>>> +static void
>>>>>> +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
>>>>>> +
>>>>>>
>>>>>>  static void
>>>>>>  eth_dev_info(struct rte_eth_dev *dev,
>>>>>> @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
>>>>>>  	dev_info->pci_dev = NULL;
>>>>>>  	dev_info->reta_size = internals->reta_size;
>>>>>>  	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
>>>>>> +	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking
>> packets in
>>>>>> /dev/null */
>>>>>> +	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
>>>>>> +	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
>>>>>
>>>>> Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
>>>>> Same question for RX.
>>>>
>>>> You could imagine, that before dropping the packet you insert the tag
>>>> and calculate the checksum. The observed effect will be the same.
>>>>
>>>> On RX this always indicates lack of VLAN tag. So whether the offload
>>>> is enabled or not it doesn't matter.
>>>
>>> Of course user can imagine whatever he likes, but what the point to advertise these capabilities,
>>> when the PMD clearly doesn't have them?
>>> Again, why these particular ones?
>>
>> Hmm. I guess we can expand the set. Those were the ones we actually use
>> (depend on) for testing our code.
>>
>> This allows to use null PMD for testing in place of real network interface
>> with those offloads. 
> 
> As I can see on TX null pmd would just drop the packets, right?
> So  the only thing you might check, as I understand, did upper layer code
> setup ol_flags  and other mbuf fields properly depending on advertised capabilities
> (probably via sme special tx_callback installed  or so).
> Is that correct? 
> That's ok, I  suppose, but if tomorrow you (or someone else) would like to test
> with different RX/TX offloads?   
> Shouldn't be advertised offload capabilities be configurable at device creation/attach time
> somehow?

This sounds good. Getting offload capabilities on runtime as devargs.

> Or at least just advertise all possible ones then?
> 
> Konstantin
> 
>> This patch is to keep users from having to place if's
>> around their code just to support test scenarios with null PMD.
>>
>> Best Regards,
>> Michał Mirosław
diff mbox

Patch

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..f32ba2a 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -284,6 +284,9 @@  eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
 	return 0;
 }
 
+static void
+eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
+
 
 static void
 eth_dev_info(struct rte_eth_dev *dev,
@@ -304,6 +307,9 @@  eth_dev_info(struct rte_eth_dev *dev,
 	dev_info->pci_dev = NULL;
 	dev_info->reta_size = internals->reta_size;
 	dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
+	/* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking packets in /dev/null */
+	dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
+	dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
 }
 
 static void
@@ -477,7 +483,12 @@  static const struct eth_dev_ops ops = {
 	.reta_update = eth_rss_reta_update,
 	.reta_query = eth_rss_reta_query,
 	.rss_hash_update = eth_rss_hash_update,
-	.rss_hash_conf_get = eth_rss_hash_conf_get
+	.rss_hash_conf_get = eth_rss_hash_conf_get,
+	/* Fake our capabilities */
+	.promiscuous_enable   = eth_dev_void_ok,
+	.promiscuous_disable  = eth_dev_void_ok,
+	.allmulticast_enable  = eth_dev_void_ok,
+	.allmulticast_disable = eth_dev_void_ok
 };
 
 int