"Michael S. Tsirkin" writes:
> On Thu, Jan 17, 2013 at 12:40:29PM +1030, Rusty Russell wrote:
>> I resist sprinkling __user everywhere because it's *not* always user
>> addresses, and it's deeply misleading to anyone reading it. I'd rather
>> have it in one place with a big comment.
>> I can try
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Jan 17, 2013 at 12:40:29PM +1030, Rusty Russell wrote:
I resist sprinkling __user everywhere because it's *not* always user
addresses, and it's deeply misleading to anyone reading it. I'd rather
have it in one place with a big comment.
I can
Rusty Russell writes:
> "Michael S. Tsirkin" writes:
>> On Wed, Jan 16, 2013 at 01:43:32PM +1030, Rusty Russell wrote:
>>> "Michael S. Tsirkin" writes:
>>> >> +static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
>>> >> +{
>>> >> +struct iovec *new;
>>> >> +unsigned int
Rusty Russell ru...@rustcorp.com.au writes:
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jan 16, 2013 at 01:43:32PM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
+static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
+{
+struct iovec *new;
+
On Thu, Jan 17, 2013 at 12:40:29PM +1030, Rusty Russell wrote:
> "Michael S. Tsirkin" writes:
> > On Wed, Jan 16, 2013 at 01:43:32PM +1030, Rusty Russell wrote:
> >> "Michael S. Tsirkin" writes:
> >> >> +static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
> >> >> +{
> >> >> + struct
On Thu, Jan 17, 2013 at 12:40:29PM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jan 16, 2013 at 01:43:32PM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
+static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
+{
+
"Michael S. Tsirkin" writes:
> On Wed, Jan 16, 2013 at 01:43:32PM +1030, Rusty Russell wrote:
>> "Michael S. Tsirkin" writes:
>> >> +static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
>> >> +{
>> >> + struct iovec *new;
>> >> + unsigned int new_num = iov->max * 2;
>> >
>> > We must limit
On Wed, Jan 16, 2013 at 01:43:32PM +1030, Rusty Russell wrote:
> "Michael S. Tsirkin" writes:
> >> +static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
> >> +{
> >> + struct iovec *new;
> >> + unsigned int new_num = iov->max * 2;
> >
> > We must limit this I think, this is coming
> >
On Wed, Jan 16, 2013 at 01:43:32PM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
+static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
+{
+ struct iovec *new;
+ unsigned int new_num = iov-max * 2;
We must limit this I think, this is coming
from
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jan 16, 2013 at 01:43:32PM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
+static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
+{
+ struct iovec *new;
+ unsigned int new_num = iov-max * 2;
We must limit
"Michael S. Tsirkin" writes:
>> +static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
>> +{
>> +struct iovec *new;
>> +unsigned int new_num = iov->max * 2;
>
> We must limit this I think, this is coming
> from userspace. How about UIO_MAXIOV?
We limit it to the ring size already;
Michael S. Tsirkin m...@redhat.com writes:
+static int resize_iovec(struct vringh_iov *iov, gfp_t gfp)
+{
+struct iovec *new;
+unsigned int new_num = iov-max * 2;
We must limit this I think, this is coming
from userspace. How about UIO_MAXIOV?
We limit it to the ring size already;
On Fri, Jan 11, 2013 at 05:07:44PM +1030, Rusty Russell wrote:
> Untested, but I wanted to post before the weekend.
>
> I think the implementation is a bit nicer, and though we have a callback
> to get the guest-to-userspace offset, it might be faster since I think
> most cases will re-use the
On Fri, Jan 11, 2013 at 05:07:44PM +1030, Rusty Russell wrote:
Untested, but I wanted to post before the weekend.
I think the implementation is a bit nicer, and though we have a callback
to get the guest-to-userspace offset, it might be faster since I think
most cases will re-use the same
Sjur Brændeland writes:
> How do you see the in-kernel API for this? I would like to see
> something similar to my previous patches, where we extend
> the virtqueue API. E.g. something like this:
> struct virtqueue *vring_new_virtqueueh(unsigned int index,
>
On Fri, Jan 11, 2013 at 7:37 AM, Rusty Russell wrote:
>virtio_host: host-side implementation of virtio rings (untested!)
>
>Getting use of virtio rings correct is tricky, and a recent patch saw
>an implementation of in-kernel rings (as separate from userspace).
How do you see the in-kernel API
On Fri, Jan 11, 2013 at 12:35 AM, Rusty Russell wrote:
> Hi Sjur!
>
> OK, the Internet was no help here, how do you pronounce Sjur?
> I'm guessing "shoor" rhyming with tour until I know better.
Thank you for asking! This is pretty close yes.
I usually tell people to pronounce it like
On Fri, Jan 11, 2013 at 12:35 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Hi Sjur!
OK, the Internet was no help here, how do you pronounce Sjur?
I'm guessing shoor rhyming with tour until I know better.
Thank you for asking! This is pretty close yes.
I usually tell people to
On Fri, Jan 11, 2013 at 7:37 AM, Rusty Russell ru...@rustcorp.com.au wrote:
virtio_host: host-side implementation of virtio rings (untested!)
Getting use of virtio rings correct is tricky, and a recent patch saw
an implementation of in-kernel rings (as separate from userspace).
How do you see
Sjur Brændeland sjurb...@gmail.com writes:
How do you see the in-kernel API for this? I would like to see
something similar to my previous patches, where we extend
the virtqueue API. E.g. something like this:
struct virtqueue *vring_new_virtqueueh(unsigned int index,
Untested, but I wanted to post before the weekend.
I think the implementation is a bit nicer, and though we have a callback
to get the guest-to-userspace offset, it might be faster since I think
most cases will re-use the same mapping.
Feedback on API welcome!
Rusty.
virtio_host: host-side
Sjur Brændeland writes:
> Hi Rusty,
>
> On Thu, Jan 10, 2013 at 11:30 AM, Rusty Russell wrote:
> ...
>>I now have some lightly-tested code (via a userspace harness).
>
> Great - thank you for looking into this. I will start integrating this
> with my patches
> when you send out a proper patch.
Hi Rusty,
On Thu, Jan 10, 2013 at 11:30 AM, Rusty Russell wrote:
...
>I now have some lightly-tested code (via a userspace harness).
Great - thank you for looking into this. I will start integrating this
with my patches
when you send out a proper patch.
...
> diff --git
On Thu, Jan 10, 2013 at 09:00:55PM +1030, Rusty Russell wrote:
> Not sure why vring/net doesn't built a packet and feed it in
> netif_rx_ni(). This is what tun seems to do, and with this code it
> should be fairly optimal.
Because we want to use NAPI.
--
MST
--
To unsubscribe from this list:
Rusty Russell writes:
> It basically involves moving much of vring.c into a virtio_host.c: the
> parts which actually touch the ring. Then it provides accessors for
> vring.c to use which are __user-safe (all casts are inside
> virtio_host.c).
>
> I should have something to post by end of today,
Hi Rusty,
On Thu, Jan 10, 2013 at 11:30 AM, Rusty Russell ru...@rustcorp.com.au wrote:
...
I now have some lightly-tested code (via a userspace harness).
Great - thank you for looking into this. I will start integrating this
with my patches
when you send out a proper patch.
...
diff --git
Sjur Brændeland sjurb...@gmail.com writes:
Hi Rusty,
On Thu, Jan 10, 2013 at 11:30 AM, Rusty Russell ru...@rustcorp.com.au wrote:
...
I now have some lightly-tested code (via a userspace harness).
Great - thank you for looking into this. I will start integrating this
with my patches
when
Untested, but I wanted to post before the weekend.
I think the implementation is a bit nicer, and though we have a callback
to get the guest-to-userspace offset, it might be faster since I think
most cases will re-use the same mapping.
Feedback on API welcome!
Rusty.
virtio_host: host-side
Rusty Russell ru...@rustcorp.com.au writes:
It basically involves moving much of vring.c into a virtio_host.c: the
parts which actually touch the ring. Then it provides accessors for
vring.c to use which are __user-safe (all casts are inside
virtio_host.c).
I should have something to post
On Thu, Jan 10, 2013 at 09:00:55PM +1030, Rusty Russell wrote:
Not sure why vring/net doesn't built a packet and feed it in
netif_rx_ni(). This is what tun seems to do, and with this code it
should be fairly optimal.
Because we want to use NAPI.
--
MST
--
To unsubscribe from this list: send
30 matches
Mail list logo
