On 7/10/2017 4:11 PM, Jerin Jacob wrote:
-----Original Message-----
I also think that the application should be able to call create() with > 1
ports. This would allow a single service to poll multiple NICs with WRR
priority.
Good point.
Can we realize the same use case like below?
- Instead of applying WRR over multiple NIC ports and adding the logic in Rx
adapter, How about applying the WRR over multiple service function and
move the WRR logic to service function layer.
i.e
one adapter is
- one service function(adapter_queue_add() will be used to add more
queues)
- one constant set of ops.
Advantages:
- WRR over service functions will be useful as other service functions
can utilize it as it is not strictly specific to Rx adapter.
- In order to work with, below mentioned use cases, RX adapter ops needs
to be constant and it will decided on the _adapter_create where "eth_port_id"
and "dev_id" specified.
1) Ethdev HW is not capable of injecting the packets and SW eventdev
driver(All existing ethdev PMD + drivers/event/sw PMD combination)
2) Ethdev HW is not capable of injecting the packets and not compatible
HW eventdev driver(All existing ethdev PMD + driver/event/octeontx PMD
combination)
3) Ethdev HW is capable of injecting the packet to compatible
HW eventdev driver.
- it will remove the below side effect(queue add/del API needs port_id)
Thoughts?
Re: Multiple ports within a adapter
1) 1:N adapter:port can work if the op is constant across all the
ports (_adapter_create() gets to determine that)
WRR is specified on a per queue basis - The polling sequence
built from the weights of all queues in the adapter (across all
ports)
struct rte_event_eth_rx_adapter_queue_conf {
...
uint16_t servicing_weight;
/**< Relative polling frequency of ethernet receive queue, if this
* is set to zero, the Rx queue is interrupt driven (unless rx queue
* interrupts are not enabled for the ethernet device)
*/
...
}
The downside is that a port needs to be specified when
add/deleting a queue. Another thought is to do away with
the concept of an adapter ID, and only use port IDs, but there
is a possibility for 2 Rx queues of the same port to be
associated with 2 different adapter IDs. from an API perspective
you could specify any of ports[i] in the info/conf() APIs and
that seems a bit odd.
In summary, I agree, lets drop this idea.
2) Re: Service function implementation of WRR
Within a service like the Rx adapter the notion of WRR is
relative polling frequency of the ethernet receive queue,
polling a tap interface may be more heavy weight than the a HW
NIC PMD poll, so WRR for the Rx adapter may not correlate with
CPU utilization i.e, if that is a metric for some other service.
If WRR is based on different metrics across services, I am not
sure how we would able to specify WRR across services. Perhaps
as services get more use, we maybe able to come up
some common requirements.
How about if multiple adapters can specify the same service,
function in the _configure() call. A service can run multiple
adapters with WRR across all queues in the service ?
Nikhil
