Ok, I've added it back with a debug log in v2.
On Tue, 2018-09-18 at 18:48 +, Louis Luo wrote:
> Hi Luca,
>
> I'm fine with the queue free part, but just have concern about
> removing the check inside uninit function. If the application does
> follow the rules and keeping the check in uninit
Hi Luca,
I'm fine with the queue free part, but just have concern about removing the
check inside uninit function. If the application does follow the rules and
keeping the check in uninit won't cause vmxnet3_dev_close() being called again
(and if it won't cause trouble in case the application d
On Tue, 2018-09-18 at 18:14 +, Louis Luo wrote:
> Hi Luca,
>
> Thanks for pointing to the document! This "basic requirements" seems
> to lay the burden on application developers to correctly follow the
> hot-plug framework's rules, but there seems no mechanism to enforce
> this procedure (corr
Hi Luca,
Thanks for pointing to the document! This "basic requirements" seems to lay the
burden on application developers to correctly follow the hot-plug framework's
rules, but there seems no mechanism to enforce this procedure (correct me if
I'm wrong). What if a buggy application doesn't cal
Hi,
The application must already stop and close before detaching (which
will call uninit). Quoting from the documentation:
"* Before detaching, they must be stopped and closed.
DPDK applications must call "rte_eth_dev_stop()" and
"rte_eth_dev_close()" APIs before detaching ports. These
Hi Luca,
When eth_vmxnet3_dev_uninit() is called, is it guaranteed that
vmxnet3_dev_close/ vmxnet3_dev_stop must have been called? I'm not familiar
with the hot-plug procedure, so just wonder if there is any chance that
eth_vmxnet3_dev_uninit() is called without calling vmxnet3_dev_close/
vmxn
6 matches
Mail list logo
