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

[Thomas Monjalon]

13/09/2017 23:42, Ananyev, Konstantin:
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > 13/09/2017 14:56, Ananyev, Konstantin:
> > > From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > Konstantin, I would like your opinion about the proposal below.
> > It is about making on the fly configuration more generic.
> > You say it is possible to configure VLAN on the fly,
> > and I think we should make it possible for other offload features.
> 
> It would be a good thing, but I don't think it is possible for all offloads.
> For some of them you still have to stop the queue(port) first. 
> 
> Also I am not sure what exactly do you propose?
> Is that something like that:
> - wipe existing offload bitfileds from rte_eth_rxmode (already done by Shahaf)
> - Instead of uint64_t offloads inside both  rte_eth_rxmode and te_eth_rxconf
>   Introduce new functions:
> 
> int rte_eth_set_port_rx_offload(portid, uint64_t offload_mask);
> int rte_eth_set_queue_rx_offload(portid, queueid, uint64_t offload_mask);
> 
> uint64_t rte_eth_get_port_rx_offload(portid);
> uint64_t rte_eth_set_queue_rx_offload(portid, queueid);
> 
> And add new fileds:
> rx_offload_port_dynamic_capa
> rx_offload_queue_dynamic_capa
> inside rte_eth_dev_info.
> 
> And it would be user responsibility to call set_port/queue_rx_offload()
> somewhere before dev_start() for static offloads.
> ?

Yes exactly.

> If so, then it seems reasonable to me.

Good, thank you


> > > > However I understand it may be better to be able to configure
> > > > per-port offloads with a dedicated per-port function.
> > > > I agree with the approach of the v3 of this series.
> > > >
> > > > Let me give my overview of offloads:
> > > >
> > > > We have simple offloads which are configured by just setting a flag.
> > > > The same flag can be set per-port or per-queue.
> > > > This offload can be set before starting or on the fly.
> > > > We currently have no generic way to set it on the fly.
> > > >
> > > > We have also more complicate offloads which require more configuration.
> > > > They are set with the rte_flow API.
> > > > They can be per-port, per-queue, on the fly or not (AFAIK).
> > > >
> > > > I think we must discuss "on the fly" capability.
> > > > It requires probably to set up simple offloads (flags) with a dedicated
> > > > function instead of using "configure" and "queue_setup" functions.
> > > > This new capability can be implemented in a different series.
> > > >
> > > > Opinions?