On 16/12/13 17:50, Wei Liu wrote:
On Mon, Dec 16, 2013 at 03:21:40PM +, Zoltan Kiss wrote:
[...]
Should this be BUG_ON? AIUI this kthread should be the only one doing
unmap, right?
The NAPI instance can do it as well if it is a small packet fits
into PKT_PROT_LEN. But still this scenario
On 16/12/13 17:50, Wei Liu wrote:
On Mon, Dec 16, 2013 at 03:21:40PM +, Zoltan Kiss wrote:
[...]
Should this be BUG_ON? AIUI this kthread should be the only one doing
unmap, right?
The NAPI instance can do it as well if it is a small packet fits
into PKT_PROT_LEN. But still this scenario
On Mon, Dec 16, 2013 at 03:21:40PM +, Zoltan Kiss wrote:
[...]
> >
> >Should this be BUG_ON? AIUI this kthread should be the only one doing
> >unmap, right?
> >>>The NAPI instance can do it as well if it is a small packet fits
> >>>into PKT_PROT_LEN. But still this scenario
On 13/12/13 19:14, Wei Liu wrote:
+ spin_lock_irqsave(>dealloc_lock, flags);
> >>+ do {
> >>+ pending_idx = ubuf->desc;
> >>+ ubuf = (struct ubuf_info *) ubuf->ctx;
> >>+ index = pending_index(vif->dealloc_prod);
> >>+ vif->dealloc_ring[index] =
On 13/12/13 19:14, Wei Liu wrote:
+ spin_lock_irqsave(vif-dealloc_lock, flags);
+ do {
+ pending_idx = ubuf-desc;
+ ubuf = (struct ubuf_info *) ubuf-ctx;
+ index = pending_index(vif-dealloc_prod);
+ vif-dealloc_ring[index] = pending_idx;
+
On Mon, Dec 16, 2013 at 03:21:40PM +, Zoltan Kiss wrote:
[...]
Should this be BUG_ON? AIUI this kthread should be the only one doing
unmap, right?
The NAPI instance can do it as well if it is a small packet fits
into PKT_PROT_LEN. But still this scenario shouldn't really happen,
I
On Fri, Dec 13, 2013 at 06:22:38PM +, Zoltan Kiss wrote:
> On 13/12/13 15:31, Wei Liu wrote:
> >On Thu, Dec 12, 2013 at 11:48:09PM +, Zoltan Kiss wrote:
> >>This patch contains the new definitions necessary for grant mapping.
> >>
> >>v2:
> >>- move unmapping to separate thread. The NAPI
On 13/12/13 15:31, Wei Liu wrote:
On Thu, Dec 12, 2013 at 11:48:09PM +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
v2:
- move unmapping to separate thread. The NAPI instance has to be scheduled
even from thread context, which can cause huge
On Thu, Dec 12, 2013 at 11:48:09PM +, Zoltan Kiss wrote:
> This patch contains the new definitions necessary for grant mapping.
>
> v2:
> - move unmapping to separate thread. The NAPI instance has to be scheduled
> even from thread context, which can cause huge delays
> - that causes
On Thu, Dec 12, 2013 at 11:48:09PM +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
v2:
- move unmapping to separate thread. The NAPI instance has to be scheduled
even from thread context, which can cause huge delays
- that causes
On 13/12/13 15:31, Wei Liu wrote:
On Thu, Dec 12, 2013 at 11:48:09PM +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
v2:
- move unmapping to separate thread. The NAPI instance has to be scheduled
even from thread context, which can cause huge
On Fri, Dec 13, 2013 at 06:22:38PM +, Zoltan Kiss wrote:
On 13/12/13 15:31, Wei Liu wrote:
On Thu, Dec 12, 2013 at 11:48:09PM +, Zoltan Kiss wrote:
This patch contains the new definitions necessary for grant mapping.
v2:
- move unmapping to separate thread. The NAPI instance has to
This patch contains the new definitions necessary for grant mapping.
v2:
- move unmapping to separate thread. The NAPI instance has to be scheduled
even from thread context, which can cause huge delays
- that causes unfortunately bigger struct xenvif
- store grant handle after checking validity
This patch contains the new definitions necessary for grant mapping.
v2:
- move unmapping to separate thread. The NAPI instance has to be scheduled
even from thread context, which can cause huge delays
- that causes unfortunately bigger struct xenvif
- store grant handle after checking validity
14 matches
Mail list logo
