search for: tx_queue_len

On 16-06-29 08:52 PM, Jason Wang wrote: > This patch introduces a new event - NETDEV_CHANGE_TX_QUEUE_LEN, this > will be triggered when tx_queue_len. It could be used by net device > who want to do some processing at that time. An example is tun who may > want to resize tx array when tx_queue_len is changed. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > in...

On 16-06-29 08:52 PM, Jason Wang wrote: > This patch introduces a new event - NETDEV_CHANGE_TX_QUEUE_LEN, this > will be triggered when tx_queue_len. It could be used by net device > who want to do some processing at that time. An example is tun who may > want to resize tx array when tx_queue_len is changed. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > in...

On 2016?06?30? 13:12, Jason Wang wrote: > > > On 2016?06?30? 12:56, John Fastabend wrote: >> On 16-06-29 08:52 PM, Jason Wang wrote: >>> This patch introduces a new event - NETDEV_CHANGE_TX_QUEUE_LEN, this >>> will be triggered when tx_queue_len. It could be used by net device >>> who want to do some processing at that time. An example is tun who may >>> want to resize tx array when tx_queue_len is changed. >>> >>> Signed-off-by: Jason Wang <jasow...

On 2016?06?30? 13:12, Jason Wang wrote: > > > On 2016?06?30? 12:56, John Fastabend wrote: >> On 16-06-29 08:52 PM, Jason Wang wrote: >>> This patch introduces a new event - NETDEV_CHANGE_TX_QUEUE_LEN, this >>> will be triggered when tx_queue_len. It could be used by net device >>> who want to do some processing at that time. An example is tun who may >>> want to resize tx array when tx_queue_len is changed. >>> >>> Signed-off-by: Jason Wang <jasow...

This patch introduces a new event - NETDEV_CHANGE_TX_QUEUE_LEN, this will be triggered when tx_queue_len. It could be used by net device who want to do some processing at that time. An example is tun who may want to resize tx array when tx_queue_len is changed. Cc: John Fastabend <john.r.fastabend at intel.com> Signed-off-by: Jason Wang <jasowang at...

On 2016?06?30? 12:56, John Fastabend wrote: > On 16-06-29 08:52 PM, Jason Wang wrote: >> This patch introduces a new event - NETDEV_CHANGE_TX_QUEUE_LEN, this >> will be triggered when tx_queue_len. It could be used by net device >> who want to do some processing at that time. An example is tun who may >> want to resize tx array when tx_queue_len is changed. >> >> Signed-off-by: Jason Wang <jasowang at redhat.com&gt...

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the ability to resize multiple rings at once to avoid handling partial resize failure for mutiple rings. - add the support for zero length ring. - introduce a notifier which was triggered when tx_...

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the ability to resize multiple rings at once to avoid handling partial resize failure for mutiple rings. - add the support for zero length ring. - introduce a notifier which was triggered when tx_...

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the ability to resize multiple rings at once to avoid handling partial resize failure for mutiple rings. - add the support for zero length ring. - introduce a notifier which was triggered when tx_...

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the ability to resize multiple rings at once to avoid handling partial resize failure for mutiple rings. - add the support for zero length ring. - introduce a notifier which was triggered when tx_...

This patch introduces a new event - NETDEV_CHANGE_TX_QUEUE_LEN, this will be triggered when tx_queue_len. It could be used by net device who want to do some processing at that time. An example is tun who may want to resize tx array when tx_queue_len is changed. Signed-off-by: Jason Wang <jasowang at redhat.com> --- include/linux/netdevice.h | 1 + net...

Hi, I''m trying to get a handle on hfsc. Here is my configuration: root@jmnrouter:/jmn# tc class show dev vlan1 class hfsc 1: root class hfsc 1:1 parent 1: ls m1 0bit d 0us m2 225000bit ul m1 0bit d 0us m2 225000bit class hfsc 1:10 parent 1:1 rt m1 191000bit d 25.0ms m2 135000bit ls m1 0bit d 0us m2 135000bit ul m1 0bit d 0us m2 225000bit class hfsc 1:20 parent 1:1 rt m1 22008bit d

...> This series tries to switch to use skb array in tun. This is used to > eliminate the spinlock contention between producer and consumer. The > conversion was straightforward: just introdce a tx skb array and use > it instead of sk_receive_queue. > > A minor issue is to keep the tx_queue_len behaviour, since tun used to > use it for the length of sk_receive_queue. This is done through: > > - add the ability to resize multiple rings at once to avoid handling > partial resize failure for mutiple rings. > - add the support for zero length ring. > - introduce a notifie...

We used to queue tx packets in sk_receive_queue, this is less efficient since it requires spinlocks to synchronize between producer and consumer. This patch tries to address this by: - switch from sk_receive_queue to a skb_array, and resize it when tx_queue_len was changed. - introduce a new proto_ops peek_len which was used for peeking the skb length. - implement a tun version of peek_len for vhost_net to use and convert vhost_net to use peek_len if possible. Pktgen test shows about 15.3% improvement on guest receiving pps for small buffers: Before...

...r_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); + + /* Random packet drop 0 => none, ~0 => all */ + if (q->loss >= net_random()) { + sch->stats.drops++; + return 0; /* lie about loss so TCP doesn''t know */ + } + + if (q->qnormal.qlen < sch->dev->tx_queue_len) { + PSCHED_GET_TIME(cb->time_to_send); + PSCHED_TADD(cb->time_to_send, q->latency); + + __skb_queue_tail(&q->qnormal, skb); + sch->q.qlen++; + sch->stats.bytes += skb->len; + sch->stats.packets++; + return 0; + } + + sch->stats.drops++; + kfree_skb(skb); + ret...

I have a bridge that has gigabit interfaces. The machine in question has the fun job of being a Bridge, Firewall and SMB server. Both of the Gigabit interfaces are connected to workstations directly via Xover cable (well MDI-X to be exact). My question is, if I enable jumbo frames on the gigabit interfaces will that make any difference in overall transfer rate of the bridge? I was thinking it

...t shows about 18% improvement on guest receiving pps for small buffers: Before: ~1220000pps After : ~1440000pps The reason why I stick to new mode is because: - though resize is supported by skb array, in multiqueue mode, it's not easy to recover from a partial success of queue resizing. - tx_queue_len is a user visible feature. Signed-off-by: Jason Wang <jasowang at redhat.com> --- - The patch is based on [PATCH v8 0/5] skb_array: array based FIFO for skbs Changes from V1: - switch to use skb array instead of a customized circular buffer - add non-blocking support - rename .peek to .peek...

...t shows about 18% improvement on guest receiving pps for small buffers: Before: ~1220000pps After : ~1440000pps The reason why I stick to new mode is because: - though resize is supported by skb array, in multiqueue mode, it's not easy to recover from a partial success of queue resizing. - tx_queue_len is a user visible feature. Signed-off-by: Jason Wang <jasowang at redhat.com> --- - The patch is based on [PATCH v8 0/5] skb_array: array based FIFO for skbs Changes from V1: - switch to use skb array instead of a customized circular buffer - add non-blocking support - rename .peek to .peek...

...goto drop; - /* Packet dropping */ + /* Drop if the filter does not like it. + * This is a noop if the filter is disabled. + * Filter can be enabled only for the TAP devices. */ + if (!check_filter(&tun->txflt, skb)) + goto drop; + if (skb_queue_len(&tun->readq) >= dev->tx_queue_len) { if (!(tun->flags & TUN_ONE_QUEUE)) { /* Normal queueing mode. */ @@ -158,7 +266,7 @@ static int tun_net_xmit(struct sk_buff *skb, struct net_device *dev) } } - /* Queue packet */ + /* Enqueue packet */ skb_queue_tail(&tun->readq, skb); dev->trans_start = jiffie...

...goto drop; - /* Packet dropping */ + /* Drop if the filter does not like it. + * This is a noop if the filter is disabled. + * Filter can be enabled only for the TAP devices. */ + if (!check_filter(&tun->txflt, skb)) + goto drop; + if (skb_queue_len(&tun->readq) >= dev->tx_queue_len) { if (!(tun->flags & TUN_ONE_QUEUE)) { /* Normal queueing mode. */ @@ -158,7 +266,7 @@ static int tun_net_xmit(struct sk_buff *skb, struct net_device *dev) } } - /* Queue packet */ + /* Enqueue packet */ skb_queue_tail(&tun->readq, skb); dev->trans_start = jiffie...