search for: mergeable_rx_buffer_size

...X queue kobjects when the netdev RX queues are resized. Is this what you had in mind: (1) Add a pointer to an attribute group to struct net_device, used for per-netdev rx queue attributes and initialized before the call to register_netdevice(). (2) Declare an attribute group containing the mergeable_rx_buffer_size attribute in virtio-net, and initialize the per-netdevice group pointer to the address of this group in virtnet_probe before register_netdevice (3) In net-sysfs, modify net_rx_queue_update_kobjects (or rx_queue_add_kobject) to call sysfs_create_group on the per-netdev attribute grou...

...X queue kobjects when the netdev RX queues are resized. Is this what you had in mind: (1) Add a pointer to an attribute group to struct net_device, used for per-netdev rx queue attributes and initialized before the call to register_netdevice(). (2) Declare an attribute group containing the mergeable_rx_buffer_size attribute in virtio-net, and initialize the per-netdevice group pointer to the address of this group in virtnet_probe before register_netdevice (3) In net-sysfs, modify net_rx_queue_update_kobjects (or rx_queue_add_kobject) to call sysfs_create_group on the per-netdev attribute grou...

...g %d\n", > vi->rq[i].min_buf_len, GOOD_PACKET_LEN, > virtqueue_get_vring_size(vi->rq[i].vq), > (int)vi->big_packets); > > after it? > Then boot and capture the output. > > Thanks! > Also, can you pls print the mergeable_rx_buffer_size attribute from sysfs for this device? > -- > MST

...g %d\n", > vi->rq[i].min_buf_len, GOOD_PACKET_LEN, > virtqueue_get_vring_size(vi->rq[i].vq), > (int)vi->big_packets); > > after it? > Then boot and capture the output. > > Thanks! > Also, can you pls print the mergeable_rx_buffer_size attribute from sysfs for this device? > -- > MST

...ev RX queues are resized. > > Is this what you had in mind: > (1) Add a pointer to an attribute group to struct net_device, used for > per-netdev rx queue attributes and initialized before the call to > register_netdevice(). > (2) Declare an attribute group containing the mergeable_rx_buffer_size > attribute in virtio-net, and initialize the per-netdevice group pointer > to the address of this group in virtnet_probe before register_netdevice > (3) In net-sysfs, modify net_rx_queue_update_kobjects > (or rx_queue_add_kobject) to call sysfs_create_group on the >...

Hi Jason, Michael Sorry for the delay in response. Jason, I agree this patch ended up being larger than expected. The major implementation parts are: (1) Setup directory structure (driver/per-netdev/rx-queue directories) (2) Network device renames (optional, so debugfs dir has the right name) (3) Support resizing the # of RX queues (optional - we could just export max_queue_pairs files and

Hi Jason, Michael Sorry for the delay in response. Jason, I agree this patch ended up being larger than expected. The major implementation parts are: (1) Setup directory structure (driver/per-netdev/rx-queue directories) (2) Network device renames (optional, so debugfs dir has the right name) (3) Support resizing the # of RX queues (optional - we could just export max_queue_pairs files and

...> > reverting that one instead? > > I tried it, and I still get slow download speeds. I did test at > 680557cf79f82623e2c4fd42733077d60a843513 during the bisect so I'm > reasonably confident that this is the one where things went bad. > > Also, could you please look at mergeable_rx_buffer_size in sysfs with > > and without the change? > > In all cases (stock 4.13-rc2, 680557cf79f8 reverted, and e377fcc8486d > reverted) mergeable_rx_buffer_size was 1536. > > Thanks, > Seth Do you see any error counters incrementing after it slows down? -- MST

...> > reverting that one instead? > > I tried it, and I still get slow download speeds. I did test at > 680557cf79f82623e2c4fd42733077d60a843513 during the bisect so I'm > reasonably confident that this is the one where things went bad. > > Also, could you please look at mergeable_rx_buffer_size in sysfs with > > and without the change? > > In all cases (stock 4.13-rc2, 680557cf79f8 reverted, and e377fcc8486d > reverted) mergeable_rx_buffer_size was 1536. > > Thanks, > Seth Do you see any error counters incrementing after it slows down? -- MST

Sorry I missed this important piece of information, it appears that netdev_queue (the TX equivalent of netdev_rx_queue) already has decoupled itself from CONFIG_XPS due to an attribute, queue_trans_timeout, that does not depend on XPS functionality. So it seems that something somewhat equivalent has already happened on the TX side. Best, Mike

Sorry I missed this important piece of information, it appears that netdev_queue (the TX equivalent of netdev_rx_queue) already has decoupled itself from CONFIG_XPS due to an attribute, queue_trans_timeout, that does not depend on XPS functionality. So it seems that something somewhat equivalent has already happened on the TX side. Best, Mike

On 12/17/2013 08:16 AM, Michael Dalton wrote: > Commit 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page frag > allocators") changed the mergeable receive buffer size from PAGE_SIZE to > MTU-size, introducing a single-stream regression for benchmarks with large > average packet size. There is no single optimal buffer size for all > workloads. For workloads

On 12/17/2013 08:16 AM, Michael Dalton wrote: > Commit 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page frag > allocators") changed the mergeable receive buffer size from PAGE_SIZE to > MTU-size, introducing a single-stream regression for benchmarks with large > average packet size. There is no single optimal buffer size for all > workloads. For workloads

...of 4.13-rc2 (along with other changes > needed to successfully revert it) speeds return to normal. > > Thanks, > Seth Interesting. A more likely suspect would be e377fcc8486d40867c6c217077ad0fa40977e060 - could you please try reverting that one instead? Also, could you please look at mergeable_rx_buffer_size in sysfs with and without the change? -- MST

...of 4.13-rc2 (along with other changes > needed to successfully revert it) speeds return to normal. > > Thanks, > Seth Interesting. A more likely suspect would be e377fcc8486d40867c6c217077ad0fa40977e060 - could you please try reverting that one instead? Also, could you please look at mergeable_rx_buffer_size in sysfs with and without the change? -- MST

I'd like to confirm the preferred sysfs path structure for mergeable receive buffers. Is 'mergeable_rx_buffer_size' the right attribute name to use or is there a strong preference for a different name? I believe the current approach proposed for the next patchset is to use a per-netdev attribute group which we will add to the receive queue kobj (struct netdev_rx_queue). That leaves us with at least two opt...

On Mon, 2014-01-13 at 11:40 +0200, Michael S. Tsirkin wrote: > On Sun, Jan 12, 2014 at 03:32:28PM -0800, Michael Dalton wrote: [...] > > The last issue is how the rx_queue_attribute 'show' function > > implementation for mergeable_rx_buffer_size will access the appropriate > > per-receive queue EWMA data. The arguments to the show function will be > > the netdev_rx_queue and the attribute itself. We can get to the > > struct net_device from the netdev_rx_queue. If we extended > > netdev_rx_queue to indicate the que...

On Mon, 2014-01-13 at 11:40 +0200, Michael S. Tsirkin wrote: > On Sun, Jan 12, 2014 at 03:32:28PM -0800, Michael Dalton wrote: [...] > > The last issue is how the rx_queue_attribute 'show' function > > implementation for mergeable_rx_buffer_size will access the appropriate > > per-receive queue EWMA data. The arguments to the show function will be > > the netdev_rx_queue and the attribute itself. We can get to the > > struct net_device from the netdev_rx_queue. If we extended > > netdev_rx_queue to indicate the que...

...ET_LEN, PAGE_SIZE - hdr_len); - len = ALIGN(len, MERGEABLE_BUFFER_ALIGN); + len = get_mergeable_buf_len(&rq->mrg_avg_pkt_len); if (unlikely(!skb_page_frag_refill(len, alloc_frag, gfp))) return -ENOMEM; @@ -1594,6 +1601,33 @@ err: return ret; } +#ifdef CONFIG_SYSFS +static ssize_t mergeable_rx_buffer_size_show(struct netdev_rx_queue *queue, + struct rx_queue_attribute *attribute, char *buf) +{ + struct virtnet_info *vi = netdev_priv(queue->dev); + unsigned int queue_index = get_netdev_rx_queue_index(queue); + struct ewma *avg; + + BUG_ON(queue_index >= vi->max_queue_pairs); + avg = &vi...

...at it, otherwise we don't really know. > Exporting the size sounds good to me, it is definitely an important metric and would give more visibility to the admin. Do you have a preference for implementation strategy? I was thinking just add a DEVICE_ATTR to create a read-only sysfs file, 'mergeable_rx_buffer_size', and return a space-separated list of the current buffer size (computed from the average packet size) for each receive queue. -EINVAL or a similar error could be returned if the netdev was not configured for mergeable rx buffers. > I don't get the real motivation for this. > > We...