search for: __skb_unlink

skb is only NULL the first time around: it's more correct to test for being under-budget. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r 2a94425ac7d5 drivers/net/virtio_net.c --- a/drivers/net/virtio_net.c Thu Nov 15 13:47:28 2007 +1100 +++ b/drivers/net/virtio_net.c Thu Nov 15 23:10:44 2007 +1100 @@ -198,8 +198,8 @@ again: if (vi->num < vi->max / 2)

skb is only NULL the first time around: it's more correct to test for being under-budget. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r 2a94425ac7d5 drivers/net/virtio_net.c --- a/drivers/net/virtio_net.c Thu Nov 15 13:47:28 2007 +1100 +++ b/drivers/net/virtio_net.c Thu Nov 15 23:10:44 2007 +1100 @@ -198,8 +198,8 @@ again: if (vi->num < vi->max / 2)

hi i tried the example given on the examples page to duplicate selected traffic like tc qdisc add dev eth0 root handle 1: prio tc qdisc add dev eth0 parent 1:3 handle 3: netem duplicate 40% tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst 11.0.2.2 flowid 1:3 when i ping from 11.0.2.2 to this interface my machine hangs. the same thing works for drop or delay. i would

...ue it again. In fact, before commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff"), we used to remove the packet from the rx_queue, only if memcpy_to_msg() was successful. Maybe it is better to do as we did before and use skb_peek() at the beginning of the loop and __skb_unlink() when skb->len == 0. Thanks, Stefano > goto out; >+ } > > spin_lock_bh(&vvs->rx_lock); > >-- >2.25.1 >

...ff state to update > 'rx_bytes' and 'fwd_cnt' correctly. >2) For SOCK_STREAM, when copying data to user fails, current skbuff is > not dropped. Next read attempt will use same skbuff and last offset. > Instead of 'skb_dequeue()', 'skb_peek()' + '__skb_unlink()' are used. > This behaviour was implemented before skbuff support. >3) For SOCK_SEQPACKET it removes unneeded 'skb_pull()' call, because for > this type of socket each skbuff is used only once: after removing it > from socket's queue, it will be freed anyway. th...

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

...ueue(dev); - /* Activate callback for using skbs: if this returns false it - * means some were used in the meantime. */ - if (unlikely(!vi->svq->vq_ops->enable_cb(vi->svq))) { - vi->svq->vq_ops->disable_cb(vi->svq); - netif_start_queue(dev); - goto again; - } - __skb_unlink(skb, &vi->send); + /* If we has a buffer left over from last time, send it now. */ + if (vi->last_xmit_skb) { + if (xmit_skb(vi, vi->last_xmit_skb) != 0) + goto stop_queue; + vi->last_xmit_skb = NULL; + } - return NETDEV_TX_BUSY; + /* Put new one in send queue and do transmit...

...ueue(dev); - /* Activate callback for using skbs: if this returns false it - * means some were used in the meantime. */ - if (unlikely(!vi->svq->vq_ops->enable_cb(vi->svq))) { - vi->svq->vq_ops->disable_cb(vi->svq); - netif_start_queue(dev); - goto again; - } - __skb_unlink(skb, &vi->send); + /* If we has a buffer left over from last time, send it now. */ + if (vi->last_xmit_skb) { + if (xmit_skb(vi, vi->last_xmit_skb) != 0) + goto stop_queue; + vi->last_xmit_skb = NULL; + } - return NETDEV_TX_BUSY; + /* Put new one in send queue and do transmit...

...'rx_bytes' and 'fwd_cnt' correctly. >>> 2) For SOCK_STREAM, when copying data to user fails, current skbuff is >>> ? not dropped. Next read attempt will use same skbuff and last offset. >>> ? Instead of 'skb_dequeue()', 'skb_peek()' + '__skb_unlink()' are used. >>> ? This behaviour was implemented before skbuff support. >>> 3) For SOCK_SEQPACKET it removes unneeded 'skb_pull()' call, because for >>> ? this type of socket each skbuff is used only once: after removing it >>> ? from socket's qu...

..._cb(vi->svq); - netif_start_queue(dev); - goto again; + /* If we has a buffer left over from last time, send it now. */ + if (vi->last_xmit_skb) { + if (xmit_skb(vi, vi->last_xmit_skb) != 0) { + /* Drop this skb: we only queue one. */ + kfree_skb(skb); + goto stop_queue; } - __skb_unlink(skb, &vi->send); + vi->last_xmit_skb = NULL; + } - return NETDEV_TX_BUSY; + /* Put new one in send queue and do transmit */ + __skb_queue_head(&vi->send, skb); + if (xmit_skb(vi, skb) != 0) { + vi->last_xmit_skb = skb; + goto stop_queue; } +done: vi->svq->vq_ops-...

..._cb(vi->svq); - netif_start_queue(dev); - goto again; + /* If we has a buffer left over from last time, send it now. */ + if (vi->last_xmit_skb) { + if (xmit_skb(vi, vi->last_xmit_skb) != 0) { + /* Drop this skb: we only queue one. */ + kfree_skb(skb); + goto stop_queue; } - __skb_unlink(skb, &vi->send); + vi->last_xmit_skb = NULL; + } - return NETDEV_TX_BUSY; + /* Put new one in send queue and do transmit */ + __skb_queue_head(&vi->send, skb); + if (xmit_skb(vi, skb) != 0) { + vi->last_xmit_skb = skb; + goto stop_queue; } +done: vi->svq->vq_ops-...

Hi again, I was just looking around for ESFQ sources, and I see that the main site is down, and only has kernel 2.6.4 patches. Is ESFQ maintained? If so, where can I find patches for 2.6.10? Thanks, -justin _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

...= (const struct netem_skb_cb *)skb->cb; + + PSCHED_GET_TIME(now); + delay = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_dequeue: delay queue %p@%lu %ld\n", + skb, jiffies, delay); + + /* it''s baked enough */ + if (delay <= 0) { + __skb_unlink(skb, &q->qdelay); + del_timer(&q->timer); + return skb; + } + + if (!timer_pending(&q->timer)) { + q->timer.expires = jiffies + delay; + add_timer(&q->timer); + } + } + return NULL; +} + +/* Dequeue packet. + * If packet needs to be held up, then put in the...

...uct sk_buff *skb; + unsigned int len; + int sent = 0; + + while ((skb = vmc_dev.sq->vq_ops->get_buf(vmc_dev.sq, &len))) + kfree_skb(skb); + + spin_lock(&vmc_dev.tx_skbuff_q.lock); + while ((skb = skb_peek(&vmc_dev.tx_skbuff_q))) { + if (vmchannel_try_send_one(skb)) + break; + __skb_unlink(skb, &vmc_dev.tx_skbuff_q); + sent++; + } + spin_unlock(&vmc_dev.tx_skbuff_q.lock); + if (sent) + vmc_dev.sq->vq_ops->kick(vmc_dev.sq); +} + +static void sendq_notify(struct virtqueue *sendq) +{ + tasklet_schedule(&vmc_dev.tx_tasklet); +} + +static int vmchannel_send_skb(struct...

...uct sk_buff *skb; + unsigned int len; + int sent = 0; + + while ((skb = vmc_dev.sq->vq_ops->get_buf(vmc_dev.sq, &len))) + kfree_skb(skb); + + spin_lock(&vmc_dev.tx_skbuff_q.lock); + while ((skb = skb_peek(&vmc_dev.tx_skbuff_q))) { + if (vmchannel_try_send_one(skb)) + break; + __skb_unlink(skb, &vmc_dev.tx_skbuff_q); + sent++; + } + spin_unlock(&vmc_dev.tx_skbuff_q.lock); + if (sent) + vmc_dev.sq->vq_ops->kick(vmc_dev.sq); +} + +static void sendq_notify(struct virtqueue *sendq) +{ + tasklet_schedule(&vmc_dev.tx_tasklet); +} + +static int vmchannel_send_skb(struct...

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c