On Tue, May 02, 2017 at 11:18:06AM +0200, Thomas Monjalon wrote:
02/05/2017 09:35, Jan Blunck:
Am 25.04.2017 11:06 schrieb "Gaëtan Rivet" <gaetan.ri...@6wind.com>:
Hi Ferruh,
On Fri, Apr 21, 2017 at 03:59:24PM +0100, Ferruh Yigit wrote:
> On 4/18/2017 1:17 PM, Gaetan Rivet wrote:
>
>> This new API allows reacting to a device removal.
>> A device removal is the sudden disappearance of a device from its
>> bus.
>>
>
I don't think this belongs into ethdev. If it is bus related we need to
expose this from it so that apps can register for the low level device
being unplugged.
Yes it sounds right.
We could work on device notifications.
We need to find a way of notifying the application that there is a
device event and that it affects one or more port at
ethdev/cryptodev/eventdev level.
This is interesting.
I developed this event with an easier integration in v17.05 in mind.
It needs a proper generic implementation however (as suggested in [1]).
I tried to have this discussion earlier[2], but without much interest.
However, even with a bus-level event framework, we still need a way for drivers
to advertize their support for specific events, and we still need to
differentiate devices that are ready for specific events from those that
do not.
So I agree that it would be interesting to have a generic rte_device
level interrupt framework to support generic events accross the whole
board, but I'm not sure it would make the dichotomy between the *driver
support* flag and the *device enabled* flag disappear.
Regards,
--
[1]: http://dpdk.org/ml/archives/dev/2017-April/064190.html
[2]: http://dpdk.org/ml/archives/dev/2017-March/060998.html
--
Gaëtan Rivet
6WIND
