On Mon, Jan 29, 2018 at 10:24 AM, Michael S. Tsirkin wrote:
> On Sun, Jan 28, 2018 at 08:26:53PM -0800, Alexander Duyck wrote:
>> >> > For live migration with advanced usecases that Siwei is suggesting, i
>> >> > think we need a new driver with a new device type that can track the
>> >> > VF speci
On Sun, Jan 28, 2018 at 08:26:53PM -0800, Alexander Duyck wrote:
> >> > For live migration with advanced usecases that Siwei is suggesting, i
> >> > think we need a new driver with a new device type that can track the
> >> > VF specific feature settings even when the VF driver is unloaded.
> >
> >
On Sun, Jan 28, 2018 at 3:02 PM, Stephen Hemminger
wrote:
> On Fri, 26 Jan 2018 18:30:03 -0800
> Jakub Kicinski wrote:
>
>> On Fri, 26 Jan 2018 15:30:35 -0800, Samudrala, Sridhar wrote:
>> > On 1/26/2018 2:47 PM, Jakub Kicinski wrote:
>> > > On Sat, 27 Jan 2018 00:14:20 +0200, Michael S. Tsirkin
On 2018年01月24日 00:03, Samudrala, Sridhar wrote:
On 1/23/2018 2:33 AM, Jason Wang wrote:
On 2018年01月12日 13:58, Sridhar Samudrala wrote:
static netdev_tx_t start_xmit(struct sk_buff *skb, struct
net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
int qnum = skb_g
On Sun, Jan 28, 2018 at 1:01 PM, Samudrala, Sridhar
wrote:
>
>
> On 1/28/2018 12:18 PM, Alexander Duyck wrote:
>>
>> On Sun, Jan 28, 2018 at 11:18 AM, Samudrala, Sridhar
>> wrote:
>>>
>>> On 1/28/2018 9:35 AM, Alexander Duyck wrote:
On Fri, Jan 26, 2018 at 9:58 PM, Jakub Kicinski wrote
On Fri, 26 Jan 2018 18:30:03 -0800
Jakub Kicinski wrote:
> On Fri, 26 Jan 2018 15:30:35 -0800, Samudrala, Sridhar wrote:
> > On 1/26/2018 2:47 PM, Jakub Kicinski wrote:
> > > On Sat, 27 Jan 2018 00:14:20 +0200, Michael S. Tsirkin wrote:
> > >> On Fri, Jan 26, 2018 at 01:46:42PM -0800, Siwei
On 1/28/2018 12:18 PM, Alexander Duyck wrote:
On Sun, Jan 28, 2018 at 11:18 AM, Samudrala, Sridhar
wrote:
On 1/28/2018 9:35 AM, Alexander Duyck wrote:
On Fri, Jan 26, 2018 at 9:58 PM, Jakub Kicinski wrote:
On Fri, 26 Jan 2018 21:33:01 -0800, Samudrala, Sridhar wrote:
3 netdev model breaks
On Sun, Jan 28, 2018 at 11:18 AM, Samudrala, Sridhar
wrote:
> On 1/28/2018 9:35 AM, Alexander Duyck wrote:
>>
>> On Fri, Jan 26, 2018 at 9:58 PM, Jakub Kicinski wrote:
>>>
>>> On Fri, 26 Jan 2018 21:33:01 -0800, Samudrala, Sridhar wrote:
>>
>> 3 netdev model breaks this configuration star
On 1/28/2018 9:35 AM, Alexander Duyck wrote:
On Fri, Jan 26, 2018 at 9:58 PM, Jakub Kicinski wrote:
On Fri, 26 Jan 2018 21:33:01 -0800, Samudrala, Sridhar wrote:
3 netdev model breaks this configuration starting with the creation
and naming of the 2 devices to udev needing to be aware of maste
On Fri, Jan 26, 2018 at 9:58 PM, Jakub Kicinski wrote:
> On Fri, 26 Jan 2018 21:33:01 -0800, Samudrala, Sridhar wrote:
>> >> 3 netdev model breaks this configuration starting with the creation
>> >> and naming of the 2 devices to udev needing to be aware of master and
>> >> slave virtio-net device
On Fri, 26 Jan 2018 21:33:01 -0800, Samudrala, Sridhar wrote:
> >> 3 netdev model breaks this configuration starting with the creation
> >> and naming of the 2 devices to udev needing to be aware of master and
> >> slave virtio-net devices.
> > I don't understand this comment. There is one virti
On 1/26/2018 6:30 PM, Jakub Kicinski wrote:
On Fri, 26 Jan 2018 15:30:35 -0800, Samudrala, Sridhar wrote:
On 1/26/2018 2:47 PM, Jakub Kicinski wrote:
On Sat, 27 Jan 2018 00:14:20 +0200, Michael S. Tsirkin wrote:
On Fri, Jan 26, 2018 at 01:46:42PM -0800, Siwei Liu wrote:
and the VM is not expe
On Fri, 26 Jan 2018 15:30:35 -0800, Samudrala, Sridhar wrote:
> On 1/26/2018 2:47 PM, Jakub Kicinski wrote:
> > On Sat, 27 Jan 2018 00:14:20 +0200, Michael S. Tsirkin wrote:
> >> On Fri, Jan 26, 2018 at 01:46:42PM -0800, Siwei Liu wrote:
> and the VM is not expected to do any tuning/optimi
On 1/26/2018 2:47 PM, Jakub Kicinski wrote:
On Sat, 27 Jan 2018 00:14:20 +0200, Michael S. Tsirkin wrote:
On Fri, Jan 26, 2018 at 01:46:42PM -0800, Siwei Liu wrote:
and the VM is not expected to do any tuning/optimizations on the VF driver
directly,
i think the current patch that follows the n
On Sat, 27 Jan 2018 00:14:20 +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 26, 2018 at 01:46:42PM -0800, Siwei Liu wrote:
> > > and the VM is not expected to do any tuning/optimizations on the VF driver
> > > directly,
> > > i think the current patch that follows the netvsc model of 2
> > > netde
On Fri, Jan 26, 2018 at 01:46:42PM -0800, Siwei Liu wrote:
> > and the VM is not expected to do any tuning/optimizations on the VF driver
> > directly,
> > i think the current patch that follows the netvsc model of 2 netdevs(virtio
> > and vf) should
> > work fine.
>
> OK. For your use case that's
On Fri, Jan 26, 2018 at 8:51 AM, Samudrala, Sridhar
wrote:
>
>
> On 1/26/2018 12:14 AM, Siwei Liu wrote:
>>
>> On Tue, Jan 23, 2018 at 2:58 PM, Michael S. Tsirkin
>> wrote:
>>>
>>> On Tue, Jan 23, 2018 at 12:24:47PM -0800, Siwei Liu wrote:
On Mon, Jan 22, 2018 at 1:41 PM, Michael S. Tsi
On 1/26/2018 8:58 AM, Michael S. Tsirkin wrote:
On Thu, Jan 11, 2018 at 09:58:39PM -0800, Sridhar Samudrala wrote:
@@ -2859,6 +3123,42 @@ static struct virtio_driver virtio_net_driver = {
#endif
};
+static int virtio_netdev_event(struct notifier_block *this,
+
On Thu, Jan 11, 2018 at 09:58:39PM -0800, Sridhar Samudrala wrote:
> @@ -2859,6 +3123,42 @@ static struct virtio_driver virtio_net_driver = {
> #endif
> };
>
> +static int virtio_netdev_event(struct notifier_block *this,
> +unsigned long event, void *ptr)
> +{
> +
On 1/26/2018 12:14 AM, Siwei Liu wrote:
On Tue, Jan 23, 2018 at 2:58 PM, Michael S. Tsirkin wrote:
On Tue, Jan 23, 2018 at 12:24:47PM -0800, Siwei Liu wrote:
On Mon, Jan 22, 2018 at 1:41 PM, Michael S. Tsirkin wrote:
On Mon, Jan 22, 2018 at 12:27:14PM -0800, Siwei Liu wrote:
First off, as
On Tue, Jan 23, 2018 at 2:58 PM, Michael S. Tsirkin wrote:
> On Tue, Jan 23, 2018 at 12:24:47PM -0800, Siwei Liu wrote:
>> On Mon, Jan 22, 2018 at 1:41 PM, Michael S. Tsirkin wrote:
>> > On Mon, Jan 22, 2018 at 12:27:14PM -0800, Siwei Liu wrote:
>> >> First off, as mentioned in another thread, th
On Tue, Jan 23, 2018 at 12:24:47PM -0800, Siwei Liu wrote:
> On Mon, Jan 22, 2018 at 1:41 PM, Michael S. Tsirkin wrote:
> > On Mon, Jan 22, 2018 at 12:27:14PM -0800, Siwei Liu wrote:
> >> First off, as mentioned in another thread, the model of stacking up
> >> virt-bond functionality over virtio s
On Mon, Jan 22, 2018 at 1:41 PM, Michael S. Tsirkin wrote:
> On Mon, Jan 22, 2018 at 12:27:14PM -0800, Siwei Liu wrote:
>> First off, as mentioned in another thread, the model of stacking up
>> virt-bond functionality over virtio seems a wrong direction to me.
>> Essentially the migration process
On 01/22/2018 04:05 PM, Samudrala, Sridhar wrote:
>
> I have been testing this feature using a shell script, but i hope
> someone in the libvirt
> community will extend 'virsh' to handle live migration when this
> feature is supported.
Each virsh command connects to a single instance of libvirtd
On 1/23/2018 2:33 AM, Jason Wang wrote:
On 2018年01月12日 13:58, Sridhar Samudrala wrote:
static netdev_tx_t start_xmit(struct sk_buff *skb, struct
net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
int qnum = skb_get_queue_mapping(skb);
struct send_queue *sq
On 2018年01月12日 13:58, Sridhar Samudrala wrote:
static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
int qnum = skb_get_queue_mapping(skb);
struct send_queue *sq = &vi->sq[qnum];
+ struct net_de
On Mon, Jan 22, 2018 at 12:27:14PM -0800, Siwei Liu wrote:
> First off, as mentioned in another thread, the model of stacking up
> virt-bond functionality over virtio seems a wrong direction to me.
> Essentially the migration process would need to carry over all guest
> side configurations previous
On 1/22/2018 12:27 PM, Siwei Liu wrote:
First off, as mentioned in another thread, the model of stacking up
virt-bond functionality over virtio seems a wrong direction to me.
Essentially the migration process would need to carry over all guest
side configurations previously done on the VF/PT and
First off, as mentioned in another thread, the model of stacking up
virt-bond functionality over virtio seems a wrong direction to me.
Essentially the migration process would need to carry over all guest
side configurations previously done on the VF/PT and get them moved to
the new device being it
This patch enables virtio_net to switch over to a VF datapath when a VF
netdev is present with the same MAC address. The VF datapath is only used
for unicast traffic. Broadcasts/multicasts go via virtio datapath so that
east-west broadcasts don't use the PCI bandwidth. It allows live migration
of a
30 matches
Mail list logo
