search for: skb_to_sgvec_nomark

...skb_to_sgvec: do not leave intermediate marks in the sgvec sg_set_buf/sg_set_page will leave the end mark in place in their argument, which may be in the middle of a scatterlist. If we remove the mark before calling them, we can avoid calls to sg_init_table before skb_to_sgvec. However, users of skb_to_sgvec_nomark now need to be careful and possibly restore the mark. Signed-off-by: Paolo Bonzini <pbonzini at redhat.com> diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 163b673f9e62..a3108ef1f1c0 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3265,6 +3265,7 @@ __skb_to_sgvec(struct...

...skb_to_sgvec: do not leave intermediate marks in the sgvec sg_set_buf/sg_set_page will leave the end mark in place in their argument, which may be in the middle of a scatterlist. If we remove the mark before calling them, we can avoid calls to sg_init_table before skb_to_sgvec. However, users of skb_to_sgvec_nomark now need to be careful and possibly restore the mark. Signed-off-by: Paolo Bonzini <pbonzini at redhat.com> diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 163b673f9e62..a3108ef1f1c0 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -3265,6 +3265,7 @@ __skb_to_sgvec(struct...

...iate marks in the sgvec > > sg_set_buf/sg_set_page will leave the end mark in place in their > argument, which may be in the middle of a scatterlist. If we > remove the mark before calling them, we can avoid calls to > sg_init_table before skb_to_sgvec. > > However, users of skb_to_sgvec_nomark now need to be careful and > possibly restore the mark. > > Signed-off-by: Paolo Bonzini <pbonzini at redhat.com> > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 163b673f9e62..a3108ef1f1c0 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c >...

...k (it cam out of of an earlier > > concern about reducing stack usage, hence the stack measurements). > > > > I like your version better than mine, except that I suspect that your > version will blow up for the same reason that my v2 patches blow up: > you probably need the skb_to_sgvec_nomark fix, too. > > IOW, what happens if you apply patches 1-4 from my v3 series and then > apply your patches on top of that? > > There'll be a hit on some virtio_pci machines due to use of the DMA > API. I would argue that, if this is measurable, the right fix is to > prod t...

...k (it cam out of of an earlier > > concern about reducing stack usage, hence the stack measurements). > > > > I like your version better than mine, except that I suspect that your > version will blow up for the same reason that my v2 patches blow up: > you probably need the skb_to_sgvec_nomark fix, too. > > IOW, what happens if you apply patches 1-4 from my v3 series and then > apply your patches on top of that? > > There'll be a hit on some virtio_pci machines due to use of the DMA > API. I would argue that, if this is measurable, the right fix is to > prod t...

...re my two patches, back-to-back (it cam out of of an earlier > concern about reducing stack usage, hence the stack measurements). > I like your version better than mine, except that I suspect that your version will blow up for the same reason that my v2 patches blow up: you probably need the skb_to_sgvec_nomark fix, too. IOW, what happens if you apply patches 1-4 from my v3 series and then apply your patches on top of that? There'll be a hit on some virtio_pci machines due to use of the DMA API. I would argue that, if this is measurable, the right fix is to prod the DMA API maintainers, whoever the...

Andy Lutomirski <luto at amacapital.net> writes: > The only unusual thing about virtio's use of scatterlists is that > two of the APIs accept scatterlists that might not be terminated. > Using function pointers to handle this case is overkill; for_each_sg > can do it. > > There's a small subtlely here: for_each_sg assumes that the provided > count is correct,

Andy Lutomirski <luto at amacapital.net> writes: > The only unusual thing about virtio's use of scatterlists is that > two of the APIs accept scatterlists that might not be terminated. > Using function pointers to handle this case is overkill; for_each_sg > can do it. > > There's a small subtlely here: for_each_sg assumes that the provided > count is correct,

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,

This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with: virtme-run --xen xen --kimg arch/x86/boot/bzImage --console using virtme from here: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git Without these patches, the guest hangs forever. With these patches,