>From: Pavan Nikhilesh Bhagavatula >> Hi Matan, >> >> >Hi Pavan >> > >> >From: Pavan Nikhilesh <pbhagavat...@marvell.com> >> >> Some PMDs cannot work when certain offloads are >enable/disabled, >> >as a >> >> workaround PMDs auto enable/disable offloads internally and >expose >> >it >> >> through dev->data->dev_conf.rxmode.offloads. >> >> >> >> After device specific dev_configure is called compare the >requested >> >offloads >> >> to the offloads exposed by the PMD and, if the PMD failed to >enable a >> >given >> >> offload then log it and return -EINVAL from >rte_eth_dev_configure, >> >else if >> >> the PMD failed to disable a given offload log and continue with >> >> rte_eth_dev_configure. >> >> >> > >> >rte_eth_dev_configure can be called more than 1 time in the device >life >> >time, How can you know what is the minimum offload configurations >> >required by the port after the first call? >> >Maybe putting it in dev info is better, what do you think? >> > >> >> We only return -EINVAL in the case where we enable an offload >advertised >> by dev_info and the port still fails to enable it. > >Are you sure it is ok that devices may disable\enable offloads under the >hood without user notification?
Some devices already do it. The above check adds validation for the same. >Can't it break applications? >Why does the device expose unsupported offloads in dev info? >Does it update the running offload usynchronically? Race? >Can you explain also your specific use case? > > >> >Matan
