[dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API

Shahaf Shuler shahafs at mellanox.com
Wed Sep 13 13:16:16 CEST 2017


Wednesday, September 13, 2017 12:28 PM, Thomas Monjalon:
> I still think we must streamline ethdev API instead of complexifying.
> We should drop the big "configure everything" and configure offloads one by
> one, and per queue (the finer grain).

The issue is, that there is some functionality which cannot be achieved when configuring offload per queue.
For example - vlan filter on intel NICs. The PF can set it even without creating a single queue, in order to enable it for the VFs.

To make it right, such functionality resides on per-device offloads. However we cannot have such concept on ethdev layer.
Also not sure we want to modify the eal for that.

> 
> More comments below
> 
> 06/09/2017 11:33, Ananyev, Konstantin:
> > From: Shahaf Shuler [mailto:shahafs at mellanox.com]
> > > Tuesday, September 5, 2017 6:31 PM, Ananyev, Konstantin:
> 
> > > > > > > > > > In fact, right now it is possible to query/change
> > > > > > > > > > these 3 vlan offload flags on the fly (after
> > > > > > > > > > dev_start) on  port basis by
> > > > > > rte_eth_dev_(get|set)_vlan_offload API.
> > > > >
> > > > > Regarding this API from ethdev.
> > > > >
> > > > > So this seems like a hack on ethdev. Currently there are 2 ways
> > > > > for user to
> > > > set Rx vlan offloads.
> > > > > One is through dev_configure which require the ports to be
> > > > > stopped. The
> > > > other is this API which can set even if the port is started.
> > > >
> > > > Yes there is an ability to enable/disable VLAN offloads without
> > > > stop/reconfigure the device.
> > > > Though I wouldn't call it 'a hack'.
> > > > From my perspective - it is a useful feature.
> > > > Same as it is possible in some cases to change MTU without
> > > > stopping device, etc.
> 
> I think the function rte_eth_dev_configure(), which set up several things at a
> time, is a very bad idea from API perspective.
> 
> In the VLAN example, we should have only one function to set this offload.
> And the PMD should advertise the capability of configuring VLAN on the fly.
> This function should return an error if called on the fly (started state) and
> PMD does not support it.
> 
> 
> > > > Consider scenario when PF has a corresponding VFs (PF is
> > > > controlled by
> > > > DPDK) Right now (at least with Intel HW) it is possible to:
> > > >
> > > > struct rte_eth_conf dev_conf;
> > > >  dev_conf. rxmode.hw_vlan_filter = 1; ...
> > > > rte_eth_dev_configure(pf_port_id, 0, 0, &dev_conf);
> > > > rte_eth_dev_start(pf_port_id);
> > > >
> > > > In that scenario I don't have any RX/TX queues configured.
> > > > Though I still able to enable vlan filter, and it would work correctly for
> VFs.
> > > > Same for other per-port offloads.
> > >
> > > For the PF - enabling vlan filtering without any queues means
> > > nothing. The PF can receive no traffic, what different does it makes the
> vlan filtering is set?
> > > For the VF - I assume it will have queues, therefore for it vlan
> > > filtering has a meaning. However as I said above, the VF has the vlan filter
> because in intel this is per-device offload, so this is not a good example.
> >
> > Yes it is a per-device offload, and right now it is possible to
> > enable/disable it via dev_confgiure(); dev_start(); without
> > configuring/starting any RX/TX queues.
> > That's an ability I'd like to preserve.
> > So from my perspective it is a perfectly valid example.
> 
> It is configuring VFs by setting the PF.
> Where is it documented?
> It looks to me as a device-specific side effect.



More information about the dev mailing list