On Wed, 18 May 2016 19:26:38 +0300
"Michael S. Tsirkin" wrote:
> On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote:
> > I agree. It is sad to see everybody is implementing the same thing,
> > open coding an array/circular based ring buffer. This kind of code is
> > hard to m
On Wed, May 18, 2016 at 09:41:03AM -0700, Eric Dumazet wrote:
> On Wed, 2016-05-18 at 19:26 +0300, Michael S. Tsirkin wrote:
> > On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote:
> > > I agree. It is sad to see everybody is implementing the same thing,
> > > open coding an arr
On Wed, 2016-05-18 at 19:26 +0300, Michael S. Tsirkin wrote:
> On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote:
> > I agree. It is sad to see everybody is implementing the same thing,
> > open coding an array/circular based ring buffer. This kind of code is
> > hard to maint
On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote:
> I agree. It is sad to see everybody is implementing the same thing,
> open coding an array/circular based ring buffer. This kind of code is
> hard to maintain and get right with barriers etc. We can achieve the
> same perfo
On Wed, 18 May 2016 18:23:48 +0800
Jason Wang wrote:
>
> >
> >
> > Maybe Steven Rostedt have an even better ring queue implementation
> > already avail in the kernel?
> >
>
> You mean ring buffer in tracing? Not sure, but it looks rather complex
> at first glance.
Yes it is, and I'm not sure
On Wed, May 18, 2016 at 06:42:10PM +0800, Jason Wang wrote:
>
>
> On 2016年05月18日 17:55, Michael S. Tsirkin wrote:
> >On Wed, May 18, 2016 at 11:21:29AM +0200, Jesper Dangaard Brouer wrote:
> >>On Wed, 18 May 2016 11:21:59 +0300
> >>"Michael S. Tsirkin" wrote:
> >>
> >>>On Wed, May 18, 2016 at 10
On 2016年05月18日 17:55, Michael S. Tsirkin wrote:
On Wed, May 18, 2016 at 11:21:29AM +0200, Jesper Dangaard Brouer wrote:
On Wed, 18 May 2016 11:21:59 +0300
"Michael S. Tsirkin" wrote:
On Wed, May 18, 2016 at 10:16:31AM +0200, Jesper Dangaard Brouer wrote:
On Tue, 17 May 2016 09:38:37 +0800
On 2016年05月18日 16:13, Jesper Dangaard Brouer wrote:
On Mon, 16 May 2016 15:51:48 +0800
Jason Wang wrote:
On 2016年05月16日 11:56, Eric Dumazet wrote:
On Mon, 2016-05-16 at 09:17 +0800, Jason Wang wrote:
We used to queue tx packets in sk_receive_queue, this is less
efficient since it requires
On Wed, May 18, 2016 at 11:21:29AM +0200, Jesper Dangaard Brouer wrote:
> On Wed, 18 May 2016 11:21:59 +0300
> "Michael S. Tsirkin" wrote:
>
> > On Wed, May 18, 2016 at 10:16:31AM +0200, Jesper Dangaard Brouer wrote:
> > >
> > > On Tue, 17 May 2016 09:38:37 +0800 Jason Wang wrote:
> > >
> >
On Wed, 18 May 2016 11:21:59 +0300
"Michael S. Tsirkin" wrote:
> On Wed, May 18, 2016 at 10:16:31AM +0200, Jesper Dangaard Brouer wrote:
> >
> > On Tue, 17 May 2016 09:38:37 +0800 Jason Wang wrote:
> >
> > > >> And if tx_queue_length is not power of 2,
> > > >> we probably need modulus to ca
On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote:
> On Mon, 16 May 2016 15:51:48 +0800
> Jason Wang wrote:
>
> > On 2016年05月16日 11:56, Eric Dumazet wrote:
> > > On Mon, 2016-05-16 at 09:17 +0800, Jason Wang wrote:
> > >> We used to queue tx packets in sk_receive_queue, thi
On Wed, May 18, 2016 at 10:16:31AM +0200, Jesper Dangaard Brouer wrote:
>
> On Tue, 17 May 2016 09:38:37 +0800 Jason Wang wrote:
>
> > >> And if tx_queue_length is not power of 2,
> > >> we probably need modulus to calculate the capacity.
> > > Is that really that important for speed?
> >
>
On Tue, 17 May 2016 09:38:37 +0800 Jason Wang wrote:
> >> And if tx_queue_length is not power of 2,
> >> we probably need modulus to calculate the capacity.
> > Is that really that important for speed?
>
> Not sure, I can test.
In my experience, yes, adding a modulus does affect performanc
On Mon, 16 May 2016 15:51:48 +0800
Jason Wang wrote:
> On 2016年05月16日 11:56, Eric Dumazet wrote:
> > On Mon, 2016-05-16 at 09:17 +0800, Jason Wang wrote:
> >> We used to queue tx packets in sk_receive_queue, this is less
> >> efficient since it requires spinlocks to synchronize between producer
On 2016年05月16日 16:08, Michael S. Tsirkin wrote:
On Mon, May 16, 2016 at 03:52:11PM +0800, Jason Wang wrote:
On 2016年05月16日 12:23, Michael S. Tsirkin wrote:
On Mon, May 16, 2016 at 09:17:01AM +0800, Jason Wang wrote:
We used to queue tx packets in sk_receive_queue, this is less
efficient sin
On Mon, May 16, 2016 at 03:52:11PM +0800, Jason Wang wrote:
>
>
> On 2016年05月16日 12:23, Michael S. Tsirkin wrote:
> >On Mon, May 16, 2016 at 09:17:01AM +0800, Jason Wang wrote:
> >>We used to queue tx packets in sk_receive_queue, this is less
> >>efficient since it requires spinlocks to synchroni
On 2016年05月16日 12:23, Michael S. Tsirkin wrote:
On Mon, May 16, 2016 at 09:17:01AM +0800, Jason Wang wrote:
We used to queue tx packets in sk_receive_queue, this is less
efficient since it requires spinlocks to synchronize between producer
and consumer.
This patch tries to address this by usi
On 2016年05月16日 11:56, Eric Dumazet wrote:
On Mon, 2016-05-16 at 09:17 +0800, Jason Wang wrote:
We used to queue tx packets in sk_receive_queue, this is less
efficient since it requires spinlocks to synchronize between producer
and consumer.
...
struct tun_struct *detached;
+ /
On Mon, May 16, 2016 at 09:17:01AM +0800, Jason Wang wrote:
> We used to queue tx packets in sk_receive_queue, this is less
> efficient since it requires spinlocks to synchronize between producer
> and consumer.
>
> This patch tries to address this by using circular buffer which allows
> lockless
On Mon, 2016-05-16 at 09:17 +0800, Jason Wang wrote:
> We used to queue tx packets in sk_receive_queue, this is less
> efficient since it requires spinlocks to synchronize between producer
> and consumer.
...
> struct tun_struct *detached;
> + /* reader lock */
> + spinlock_t rlock;
We used to queue tx packets in sk_receive_queue, this is less
efficient since it requires spinlocks to synchronize between producer
and consumer.
This patch tries to address this by using circular buffer which allows
lockless synchronization. This is done by switching from
sk_receive_queue to a tx
21 matches
Mail list logo