Re: [Qemu-devel] [PATCH 00/16] Add a -netdev option

2009-11-10 Thread Paul Brook
On Thursday 08 October 2009, Mark McLoughlin wrote:
 Hi,
 Here's a series of patches which gets the ball rolling on adding
 a -netdev option.
...
 The idea is to de-emphasise the vlan support, and instead make
 a nic directly connected to a host backend the default and recommended
 configuration. We want this because it is only with this configuration
 that we feasibly add optimizations like GSO support or vhost-net.

If we're going to introduce point-point connections then IMO everything should 
be a point-point connection. Having separate point-point and multiple-peer 
cases is just going to come back and bite us later.

Once you have a symmetric point-point API, negotiation of features (such as 
offload, filtering, etc) should be relatively straightforward.  Device 
creation and port connection should be separate events, with feature 
negotiation occurring at connection. This gives you hotplug for free, and 
avoids ordering issues.  vlan functionality is implemented via a fairly 
trivial hub device that has many ports and doesn't implement any of the fancy 
optional features.

Paul




Re: [Qemu-devel] [PATCH 00/16] Add a -netdev option

2009-11-10 Thread Mark McLoughlin
On Tue, 2009-11-10 at 15:44 +, Paul Brook wrote:
 On Thursday 08 October 2009, Mark McLoughlin wrote:
  Hi,
  Here's a series of patches which gets the ball rolling on adding
  a -netdev option.
 ...
  The idea is to de-emphasise the vlan support, and instead make
  a nic directly connected to a host backend the default and recommended
  configuration. We want this because it is only with this configuration
  that we feasibly add optimizations like GSO support or vhost-net.
 
 If we're going to introduce point-point connections then IMO everything 
 should 
 be a point-point connection. Having separate point-point and multiple-peer 
 cases is just going to come back and bite us later.
 
 Once you have a symmetric point-point API, negotiation of features (such as 
 offload, filtering, etc) should be relatively straightforward.  Device 
 creation and port connection should be separate events, with feature 
 negotiation occurring at connection. This gives you hotplug for free, and 
 avoids ordering issues.  vlan functionality is implemented via a fairly 
 trivial hub device that has many ports and doesn't implement any of the fancy 
 optional features.

Yep, that's roughly the plan.

Cheers,
Mark.