search for: skbs

On Thursday 01 May 2008 00:31:46 Mark McLoughlin wrote: > virtio_net currently only frees old transmit skbs just > before queueing new ones. If the queue is full, it then > enables interrupts and waits for notification that more > work has been performed. Hi Mark, This patch is fine, but it's better to do it from skb_xmit_done(). Of course, this is usually called from an interrupt han...

On Thursday 01 May 2008 00:31:46 Mark McLoughlin wrote: > virtio_net currently only frees old transmit skbs just > before queueing new ones. If the queue is full, it then > enables interrupts and waits for notification that more > work has been performed. Hi Mark, This patch is fine, but it's better to do it from skb_xmit_done(). Of course, this is usually called from an interrupt han...

Hi, Back in October I reported that I noticed a problem whereby flow control breaks down when openvswitch is configured to mirror a port[1]. I have (finally) looked into this further and the problem appears to relate to cloning of skbs, as Jesse Gross originally suspected. More specifically, in do_execute_actions[2] the first n-1 times that an skb needs to be transmitted it is cloned first and the final time the original skb is used. In the case that there is only one action, which is the normal case, then the original skb will...

Hi, Back in October I reported that I noticed a problem whereby flow control breaks down when openvswitch is configured to mirror a port[1]. I have (finally) looked into this further and the problem appears to relate to cloning of skbs, as Jesse Gross originally suspected. More specifically, in do_execute_actions[2] the first n-1 times that an skb needs to be transmitted it is cloned first and the final time the original skb is used. In the case that there is only one action, which is the normal case, then the original skb will...

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1233846695 0 # Node ID 7a24febd95d5abfc03e05de7fa991b11cef14eef # Parent 4f998fd102e24daa471482730d1a3ff68faa1ad6 netback: add ethtool stat to track copied skbs. copied skbs should be rare but we have no way of verifying that. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 4f998fd102e2 -r 7a24febd95d5 drivers/xen/netback/common.h --- a/drivers/xen/netback/common.h Wed Feb 04 12:26:00 2009 +0000 +++ b/drivers/xen/netback/common.h Thu...

...gt;>> Shouldn't max_pend then be tied to the ring size if it's small? >>> >> >> Yes it should. I just reuse the VHOST_MAX_PEND since it was there for a >> long time. >>> Another question is about stopping vhost: >>> ATM it's waiting for skbs to complete. >>> Should we maybe hunt down skbs queued and destroy them >>> instead? >>> I think this happens when a device is removed. >>> >>> Thoughts? >>> >> >> Agree, vhost net removal should not be blocked by a skb. But since th...

...gt;>> Shouldn't max_pend then be tied to the ring size if it's small? >>> >> >> Yes it should. I just reuse the VHOST_MAX_PEND since it was there for a >> long time. >>> Another question is about stopping vhost: >>> ATM it's waiting for skbs to complete. >>> Should we maybe hunt down skbs queued and destroy them >>> instead? >>> I think this happens when a device is removed. >>> >>> Thoughts? >>> >> >> Agree, vhost net removal should not be blocked by a skb. But since th...

We check for finished xmit skbs on every xmit, or on a timer (unless the host promises to force an interrupt when the xmit ring is empty). This can penalize userspace tasks which fill their sockbuf. Not much difference with TSO, but measurable with large numbers of packets. There are a finite number of packets which can be in t...

We check for finished xmit skbs on every xmit, or on a timer (unless the host promises to force an interrupt when the xmit ring is empty). This can penalize userspace tasks which fill their sockbuf. Not much difference with TSO, but measurable with large numbers of packets. There are a finite number of packets which can be in t...

...> >> >>>> > >>Yes it should. I just reuse the VHOST_MAX_PEND since it was there for a >>>> > >>long time. >>>>> > >>>Another question is about stopping vhost: >>>>> > >>>ATM it's waiting for skbs to complete. >>>>> > >>>Should we maybe hunt down skbs queued and destroy them >>>>> > >>>instead? >>>>> > >>>I think this happens when a device is removed. >>>>> > >>> >>>>> &...

...> >> >>>> > >>Yes it should. I just reuse the VHOST_MAX_PEND since it was there for a >>>> > >>long time. >>>>> > >>>Another question is about stopping vhost: >>>>> > >>>ATM it's waiting for skbs to complete. >>>>> > >>>Should we maybe hunt down skbs queued and destroy them >>>>> > >>>instead? >>>>> > >>>I think this happens when a device is removed. >>>>> > >>> >>>>> &...

hi, I seem to have a problem with the Linux xen-network driver leaking skbs. This is probably my own fault, upon resumption after migration I call this: void network_resume(void) { struct net_device* dev = __dev_get_by_name("eth0"); MOD_DEC_USE_COUNT; network_open(dev); } -- which works fine. However, in network_open() the call to NETOP_RESET_RINGS...

An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20080714/4cbde0fc/attachment.txt

Dear list members (especially Xen network wizards), I''m using the netfilter_queue mechanism to modify packets on the wire that are sent from one domU to another while they travel over the dom0 bridge. This has worked fine as long as I was tinkering with UDP packets only - but when I try to reinject TCP frames with an increased length, I run into a BUG() because

An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20080714/4cbde0fc/attachment.txt

...a look at this one. Virtio is the guest side of things. Guest kernel virtio-net: TX: - Guest kernel allocates a packet (skb) in guest kernel memory and fills it in with data, passes it to networking stack. - The skb is passed on to guest network driver (hard_start_xmit) - skbs in flight are kept in send queue linked list, so that we can flush them when device is removed [ mst: optimization idea: virtqueue already tracks posted buffers. Add flush/purge operation and use that instead? ] - skb is reformatted to scattergather format [ mst:...

...a look at this one. Virtio is the guest side of things. Guest kernel virtio-net: TX: - Guest kernel allocates a packet (skb) in guest kernel memory and fills it in with data, passes it to networking stack. - The skb is passed on to guest network driver (hard_start_xmit) - skbs in flight are kept in send queue linked list, so that we can flush them when device is removed [ mst: optimization idea: virtqueue already tracks posted buffers. Add flush/purge operation and use that instead? ] - skb is reformatted to scattergather format [ mst:...

...VHOST_MAX_PEND > is much smaller than the ring size. > Shouldn't max_pend then be tied to the ring size if it's small? > Yes it should. I just reuse the VHOST_MAX_PEND since it was there for a long time. > Another question is about stopping vhost: > ATM it's waiting for skbs to complete. > Should we maybe hunt down skbs queued and destroy them > instead? > I think this happens when a device is removed. > > Thoughts? > Agree, vhost net removal should not be blocked by a skb. But since the skbs could be queued may places, just destroy them may need ex...

...VHOST_MAX_PEND > is much smaller than the ring size. > Shouldn't max_pend then be tied to the ring size if it's small? > Yes it should. I just reuse the VHOST_MAX_PEND since it was there for a long time. > Another question is about stopping vhost: > ATM it's waiting for skbs to complete. > Should we maybe hunt down skbs queued and destroy them > instead? > I think this happens when a device is removed. > > Thoughts? > Agree, vhost net removal should not be blocked by a skb. But since the skbs could be queued may places, just destroy them may need ex...

Some deivces do not free the old tx skbs immediately after it has been sent (usually in tx interrupt). One such example is virtio-net which optimizes for virt and only free the possible old tx skbs during the next packet sending. This would lead the pktgen to wait forever in the refcount of the skb if no other pakcet will be sent afterwar...