search for: interurpts

Displaying 14 results from an estimated 14 matches for "interurpts".

Did you mean: interrupts
2014 Dec 02
2
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...t;I'm not sure the regression is due to interrupts. > >>It would make sense for CPU but why would it > >>hurt transaction rate? > > > >Anyway guest need to take some cycles to handle tx interrupts. > >And transaction rate does increase if we coalesces more tx interurpts. > >> > >> > >>It's possible that we are deferring kicks too much due to BQL. > >> > >>As an experiment: do we get any of it back if we do > >>- if (kick || netif_xmit_stopped(txq)) > >>- virtqueue_kick(sq->...
2014 Dec 02
2
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...t;I'm not sure the regression is due to interrupts. > >>It would make sense for CPU but why would it > >>hurt transaction rate? > > > >Anyway guest need to take some cycles to handle tx interrupts. > >And transaction rate does increase if we coalesces more tx interurpts. > >> > >> > >>It's possible that we are deferring kicks too much due to BQL. > >> > >>As an experiment: do we get any of it back if we do > >>- if (kick || netif_xmit_stopped(txq)) > >>- virtqueue_kick(sq->...
2014 Dec 02
2
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...nterrupts. > >> >>It would make sense for CPU but why would it > >> >>hurt transaction rate? > >> > > >> >Anyway guest need to take some cycles to handle tx interrupts. > >> >And transaction rate does increase if we coalesces more tx interurpts. > >> >> > >> >> > >> >>It's possible that we are deferring kicks too much due to BQL. > >> >> > >> >>As an experiment: do we get any of it back if we do > >> >>- if (kick || netif_xmit_stopped(txq)...
2014 Dec 02
2
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...nterrupts. > >> >>It would make sense for CPU but why would it > >> >>hurt transaction rate? > >> > > >> >Anyway guest need to take some cycles to handle tx interrupts. > >> >And transaction rate does increase if we coalesces more tx interurpts. > >> >> > >> >> > >> >>It's possible that we are deferring kicks too much due to BQL. > >> >> > >> >>As an experiment: do we get any of it back if we do > >> >>- if (kick || netif_xmit_stopped(txq)...
2014 Dec 02
0
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...> >>It would make sense for CPU but why would it > > >> >>hurt transaction rate? > > >> > > > >> >Anyway guest need to take some cycles to handle tx interrupts. > > >> >And transaction rate does increase if we coalesces more tx interurpts. > > >> >> > > >> >> > > >> >>It's possible that we are deferring kicks too much due to BQL. > > >> >> > > >> >>As an experiment: do we get any of it back if we do > > >> >>- if (k...
2014 Dec 02
4
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
....rate. (reduce 40%-80% tx intrs) > > I'm not sure the regression is due to interrupts. > It would make sense for CPU but why would it > hurt transaction rate? Anyway guest need to take some cycles to handle tx interrupts. And transaction rate does increase if we coalesces more tx interurpts. > > > It's possible that we are deferring kicks too much due to BQL. > > As an experiment: do we get any of it back if we do > - if (kick || netif_xmit_stopped(txq)) > - virtqueue_kick(sq->vq); > + virtqueue_kick(sq->vq); > ?...
2014 Dec 02
4
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
....rate. (reduce 40%-80% tx intrs) > > I'm not sure the regression is due to interrupts. > It would make sense for CPU but why would it > hurt transaction rate? Anyway guest need to take some cycles to handle tx interrupts. And transaction rate does increase if we coalesces more tx interurpts. > > > It's possible that we are deferring kicks too much due to BQL. > > As an experiment: do we get any of it back if we do > - if (kick || netif_xmit_stopped(txq)) > - virtqueue_kick(sq->vq); > + virtqueue_kick(sq->vq); > ?...
2014 Dec 02
0
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...s due to interrupts. >> >>It would make sense for CPU but why would it >> >>hurt transaction rate? >> > >> >Anyway guest need to take some cycles to handle tx interrupts. >> >And transaction rate does increase if we coalesces more tx >> interurpts. >> >> >> >> >> >>It's possible that we are deferring kicks too much due to BQL. >> >> >> >>As an experiment: do we get any of it back if we do >> >>- if (kick || netif_xmit_stopped(txq)) >> >>-...
2014 Dec 02
0
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...s due to interrupts. >> >>It would make sense for CPU but why would it >> >>hurt transaction rate? >> > >> >Anyway guest need to take some cycles to handle tx interrupts. >> >And transaction rate does increase if we coalesces more tx >> interurpts. >> >> >> >> >> >>It's possible that we are deferring kicks too much due to BQL. >> >> >> >>As an experiment: do we get any of it back if we do >> >>- if (kick || netif_xmit_stopped(txq)) >> >>-...
2014 Dec 02
0
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...d make sense for CPU but why would it > > > >> >>hurt transaction rate? > > > >> > > > > >> >Anyway guest need to take some cycles to handle tx interrupts. > > > >> >And transaction rate does increase if we coalesces more tx interurpts. > > > >> >> > > > >> >> > > > >> >>It's possible that we are deferring kicks too much due to BQL. > > > >> >> > > > >> >>As an experiment: do we get any of it back if we do > > > &...
2014 Dec 02
0
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...;> >> I'm not sure the regression is due to interrupts. >> It would make sense for CPU but why would it >> hurt transaction rate? > > Anyway guest need to take some cycles to handle tx interrupts. > And transaction rate does increase if we coalesces more tx > interurpts. >> >> >> It's possible that we are deferring kicks too much due to BQL. >> >> As an experiment: do we get any of it back if we do >> - if (kick || netif_xmit_stopped(txq)) >> - virtqueue_kick(sq->vq); >> + virt...
2014 Dec 02
0
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
...;> >> I'm not sure the regression is due to interrupts. >> It would make sense for CPU but why would it >> hurt transaction rate? > > Anyway guest need to take some cycles to handle tx interrupts. > And transaction rate does increase if we coalesces more tx > interurpts. >> >> >> It's possible that we are deferring kicks too much due to BQL. >> >> As an experiment: do we get any of it back if we do >> - if (kick || netif_xmit_stopped(txq)) >> - virtqueue_kick(sq->vq); >> + virt...
2014 Dec 01
9
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
Hello: We used to orphan packets before transmission for virtio-net. This breaks socket accounting and can lead serveral functions won't work, e.g: - Byte Queue Limit depends on tx completion nofication to work. - Packet Generator depends on tx completion nofication for the last transmitted packet to complete. - TCP Small Queue depends on proper accounting of sk_wmem_alloc to work. This
2014 Dec 01
9
[PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts
Hello: We used to orphan packets before transmission for virtio-net. This breaks socket accounting and can lead serveral functions won't work, e.g: - Byte Queue Limit depends on tx completion nofication to work. - Packet Generator depends on tx completion nofication for the last transmitted packet to complete. - TCP Small Queue depends on proper accounting of sk_wmem_alloc to work. This