> On 7 Mar 2019, at 18:57, Jim Thompson <[email protected]> wrote:
> 
> 
> 
>> On Mar 7, 2019, at 11:52 AM, Damjan Marion via Lists.Fd.Io 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>> 
>> 
>>> On 7 Mar 2019, at 18:33, Matthew Smith <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> 
>>> Hi all,
>>> 
>>> At startup, the DPDK plugin attempts to take over most PCI network devices 
>>> which are supported by a PMD and are not in use by the kernel. It seems 
>>> that vmxnet3 is an exception to this - if vmxnet3 devices are present, they 
>>> are blacklisted unless they were explicitly whitelisted in  startup.conf. I 
>>> presume that this is so you could use the vmxnet3 plugin to manage those 
>>> devices.
>>> 
>>> Would it be acceptable to have the DPDK plugin treat vmxnet3 like other 
>>> device types unless it's explicitly blacklisted? We use VPP on various 
>>> platforms with different types of physical and virtual NICs. Since we don't 
>>> know at build time how many interfaces will be attached to a VM or what all 
>>> of the PCI addresses of those devices will be, it's hard to package a 
>>> default startup.conf that whitelists the right device IDs for a given VM. 
>>> The default behavior of the DPDK plugin has been very useful because it 
>>> usually makes all of the available interfaces manageable when a new VM is 
>>> brought up. In order to make vmxnet3 interfaces manageable on a newly 
>>> created VM, we would need to run something at startup to figure out which 
>>> vxmnet3 devices are available and explicitly whitelist them in the DPDK 
>>> plugin configuration or to set them up to be managed by the vmxnet3 plugin. 
>>> This is certainly possible, but it would be nice if we could avoid the 
>>> extra complication and have vmxnet3 devices behave like other devices.
>>> 
>>> If we submitted a patch that removed the auto-blacklisting of vmxnet3, 
>>> would there be any objections to that?
>> 
>> My preference is that it stays as it is so people can have choice instead of 
>> being forced to use dpdk implementation.
>> You can easily write simple script which goes trough /sys/bus/pci/devices 
>> and whitelists whatever you like…
> 
> Damjan,
> 
> The issue here is (default?) behavior.   Yes, we can simply carry a patch to 
> reverse the behavior of vmxnet3, but the point is that it behaves differently 
> than the (other) DPDK PMDs.

What about making others to behave like vmxnet3 instead, that will be also 
default and more polite behaviour that what we have today.
Unbinding all interfaces on the system (including the ones which are up and 
running but assigned to different network namespace) is quite rude...

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12462): https://lists.fd.io/g/vpp-dev/message/12462
Mute This Topic: https://lists.fd.io/mt/30299692/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to