07/07/2017 16:08, Guo, Jia:
>
> On 7/7/2017 6:17 PM, Thomas Monjalon wrote:
> > 07/07/2017 09:56, Thomas Monjalon:
> >> 29/06/2017 07:01, Jeff Guo:
> >>> --- a/drivers/net/i40e/i40e_ethdev.c
> >>> +++ b/drivers/net/i40e/i40e_ethdev.c
> >>> @@ -1283,6 +1283,7 @@ static inline void i40e_GLQF_reg_init(struct
> >>> i40e_hw *hw)
> >>>
> >>> /* enable uio intr after callback register */
> >>> rte_intr_enable(intr_handle);
> >>> +
> >>> /*
> >>> * Add an ethertype filter to drop all flow control frames
> >>> transmitted
> >>> * from VSIs. By doing so, we stop VF from sending out PAUSE or
> >>> PFC
> >>> @@ -5832,11 +5833,29 @@ struct i40e_vsi *
> >>> {
> >>> struct rte_eth_dev *dev = (struct rte_eth_dev *)param;
> >>> struct i40e_hw *hw =
> >>> I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> >>> + struct rte_uevent event;
> >>> uint32_t icr0;
> >>> + struct rte_pci_device *pci_dev;
> >>> + struct rte_intr_handle *intr_handle;
> >>> +
> >>> + pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> >>> + intr_handle = &pci_dev->intr_handle;
> >>>
> >>> /* Disable interrupt */
> >>> i40e_pf_disable_irq0(hw);
> >>>
> >>> + /* check device uevent */
> >>> + if (rte_uevent_get(intr_handle->uevent_fd, &event) == 0) {
> >>> + if (event.subsystem == RTE_UEVENT_SUBSYSTEM_UIO) {
> >>> + if (event.action == RTE_UEVENT_REMOVE) {
> >>> + _rte_eth_dev_callback_process(dev,
> >>> + RTE_ETH_EVENT_INTR_RMV, NULL);
> >>> + return;
> >>> + }
> >>> + }if
> >>> + goto done;
> >>> + }
> >> There is nothing specific to i40e in this patch.
> >> It seems wrong to add such generic code in every drivers.
> > It should be managed at bus layer and not be specific to ethdev only.
> if all could managed at bus layer might also be what i want to see,
> but that would not so economical at currently. because of the event need
> to exposure to driver to use app's callback to handle it by
> detach/attach device. mlx driver also go through this path to show the
> rmv event usege. we just add uevent for pci uio device. Anyway, i think
> the uevent must be useful for future PF/VFIO live migration. if there
> are not other concern about the other patch that added uevent api in
> eal([PATCH v3 1/2] eal: add uevent api for hot plug), i suggest to merge
> it at first. Then we could go next to enhancement it with the 6wind hot
> plug feature.
Sorry it looks wrong to apply half of this patchset, given we are not
sure how the remaining part should be implemented.
Let's take time for a better solution and try to gather more opinions.
It will be highlighted as one of the next priorities, after the bus rework
in progress.
