On Mon, Jun 04, 2007 at 02:25:32PM +0300, Avi Kivity wrote:
>
> OT: Does that hold for bonded interfaces too?
Yes. By default traffic to the same destination MAC always stick to
one interface. You could select a layer3+4 hashing policy but even
that guarantees a single flow will stick to one ph
On Mon, 2007-06-04 at 14:25 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> >
> >> Networking hardware generally services descriptors in a FIFO manner.
> >>
> >
> > Well, ethernet guarantees order. Not sure about others tho...
>
> OT: Does that hold for bonded interfaces too?
Sorry, I
Rusty Russell wrote:
>
>> Networking hardware generally services descriptors in a FIFO manner.
>>
>
> Well, ethernet guarantees order. Not sure about others tho...
>
>
OT: Does that hold for bonded interfaces too?
>> virtio may not (for example, it may offload copies of larger packets
On Mon, 2007-06-04 at 12:55 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > On Sun, 2007-06-03 at 14:39 +0300, Avi Kivity wrote:
> >
> >> Rusty Russell wrote:
> >>
> >>> Hmm... Perhaps I should move the used arrays into the "struct
> >>> virtio_device" and guarantee that the id (returne
On Sun, 2007-06-03 at 08:28 +0300, Avi Kivity wrote:
> Sure, 'used' is important (how else do you get the packet size on
> receive?)
Well, the sender can prepend the length, or for networking just leave
Linux to trim packets. It's the trust issue which bugs me.
> , I'm just bitching about the l
Rusty Russell wrote:
> On Sat, 2007-06-02 at 09:30 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> + * virtio_ops - virtio abstraction layer
>>> + * @add_outbuf: prepare to send data to the other end:
>>> + * vdev: the virtio_device
>>> + * sg: the description of the buffer(s).
>>
On Sat, 2007-06-02 at 09:30 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > + * virtio_ops - virtio abstraction layer
> > + * @add_outbuf: prepare to send data to the other end:
> > + * vdev: the virtio_device
> > + * sg: the description of the buffer(s).
> > + * num: the size of the sg array.
Rusty Russell wrote:
> This attempts to implement a "virtual I/O" layer which should allow
> common drivers to be efficiently used across most virtual I/O
> mechanisms. It will no-doubt need further enhancement.
>
> The details of probing the device are left to hypervisor-specific
> code: it simpl
>This attempts to implement a "virtual I/O" layer which should allow
>common drivers to be efficiently used across most virtual I/O
>mechanisms. It will no-doubt need further enhancement.
>
>The details of probing the device are left to hypervisor-specific
>code: it simple constructs the "struct v
Rusty Russell wrote:
> This attempts to implement a "virtual I/O" layer which should allow
> common drivers to be efficiently used across most virtual I/O
> mechanisms. It will no-doubt need further enhancement.
>
> The details of probing the device are left to hypervisor-specific
> code: it simp
This attempts to implement a "virtual I/O" layer which should allow
common drivers to be efficiently used across most virtual I/O
mechanisms. It will no-doubt need further enhancement.
The details of probing the device are left to hypervisor-specific
code: it simple constructs the "struct virtio_
11 matches
Mail list logo
