search for: netdev_rx_queue

...12, 2014 at 9:09 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > Can't we add struct attribute * to netdevice, and pass that in when > creating the kobj? I like that idea, I think that will work and should be better than the alternatives. The actual kobjs for RX queues (struct netdev_rx_queue) are allocated and deallocated by calls to net_rx_queue_update_kobjects, which resizes RX 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 be...

...12, 2014 at 9:09 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > Can't we add struct attribute * to netdevice, and pass that in when > creating the kobj? I like that idea, I think that will work and should be better than the alternatives. The actual kobjs for RX queues (struct netdev_rx_queue) are allocated and deallocated by calls to net_rx_queue_update_kobjects, which resizes RX 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 be...

...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 queue_index or to store a void *priv_data > > pointer, that would be sufficient to allow us to resolve this issue. > > Hmm netdev_...

...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 queue_index or to store a void *priv_data > > pointer, that would be sufficient to allow us to resolve this issue. > > Hmm netdev_...

...ux/netdevice.h @@ -668,15 +668,28 @@ extern struct rps_sock_flow_table __rcu *rps_sock_flow_table; bool rps_may_expire_flow(struct net_device *dev, u16 rxq_index, u32 flow_id, u16 filter_id); #endif +#endif /* CONFIG_RPS */ /* This structure contains an instance of an RX queue. */ struct netdev_rx_queue { +#ifdef CONFIG_RPS struct rps_map __rcu *rps_map; struct rps_dev_flow_table __rcu *rps_flow_table; +#endif struct kobject kobj; struct net_device *dev; } ____cacheline_aligned_in_smp; -#endif /* CONFIG_RPS */ + +/* + * RX queue sysfs structures and functions. + */ +struct rx_queue_at...

...s attributes to permit a device-specific attribute group. Initial use case for this support will be to allow the virtio-net device to export per-receive queue mergeable receive buffer size. Signed-off-by: Michael Dalton <mwdalton at google.com> --- v3->v4: Simplify by removing loop in get_netdev_rx_queue_index. include/linux/netdevice.h | 35 +++++++++++++++++++++++++++++++---- net/core/dev.c | 12 ++++++------ net/core/net-sysfs.c | 33 ++++++++++++++++----------------- 3 files changed, 53 insertions(+), 27 deletions(-) diff --git a/include/linux/netdevice.h b/include/linux/netd...

...ueue files for all RX queues supported by the netdev, rather than dynamically displaying only the files corresponding to enabled RX queues (e.g., when # of RX queues is changed by ethtool -L <device>). For an example of this approach, see drivers/net/bonding/bond_sysfs.c. (c) Modify struct netdev_rx_queue to add virtio-net EWMA fields directly, and modify net-sysfs.c to manage the new fields. Unlike (b), this approach supports the RX queue resizing in (3) but means putting virtio-net info in netdev_rx_queue, which currently has only device-independent fields. My preference would be (b): try using s...

...ueue files for all RX queues supported by the netdev, rather than dynamically displaying only the files corresponding to enabled RX queues (e.g., when # of RX queues is changed by ethtool -L <device>). For an example of this approach, see drivers/net/bonding/bond_sysfs.c. (c) Modify struct netdev_rx_queue to add virtio-net EWMA fields directly, and modify net-sysfs.c to manage the new fields. Unlike (b), this approach supports the RX queue resizing in (3) but means putting virtio-net info in netdev_rx_queue, which currently has only device-independent fields. My preference would be (b): try using s...

...hael S. Tsirkin <mst at redhat.com> wrote: > > Can't we add struct attribute * to netdevice, and pass that in when > > creating the kobj? > > I like that idea, I think that will work and should be better than > the alternatives. The actual kobjs for RX queues (struct netdev_rx_queue) > are allocated and deallocated by calls to net_rx_queue_update_kobjects, > which resizes RX 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...

...Ben Hutchings <bhutchings at solarflare.com> wrote: > I don't think RPS should own this structure. It's just that there are > currently no per-RX-queue attributes other than those defined by RPS. Agreed, there is useful attribute-independent functionality already built around netdev_rx_queue - e.g., dynamically resizing the rx queue kobjs as the number of RX queues enabled for the netdev is changed. While the current attributes happen to be used only by RPS, AFAICT it seems RPS should not own netdev_rx_queue but rather should own the RPS-specific fields themselves within netdev_rx_queu...

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

skb_page_frag_refill currently permits only order-0 page allocs unless GFP_WAIT is used. Change skb_page_frag_refill to attempt higher-order page allocations whether or not GFP_WAIT is used. If memory cannot be allocated, the allocator will fall back to successively smaller page allocs (down to order-0 page allocs). This change brings skb_page_frag_refill in line with the existing page allocation

The virtio-net device currently uses aligned MTU-sized mergeable receive packet buffers. Network throughput for workloads with large average packet size can be improved by posting larger receive packet buffers. However, due to SKB truesize effects, posting large (e.g, PAGE_SIZE) buffers reduces the throughput of workloads that do not benefit from GRO and have no large inbound packets. This

The virtio-net device currently uses aligned MTU-sized mergeable receive packet buffers. Network throughput for workloads with large average packet size can be improved by posting larger receive packet buffers. However, due to SKB truesize effects, posting large (e.g, PAGE_SIZE) buffers reduces the throughput of workloads that do not benefit from GRO and have no large inbound packets. This

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

The virtio-net device currently uses aligned MTU-sized mergeable receive packet buffers. Network throughput for workloads with large average packet size can be improved by posting larger receive packet buffers. However, due to SKB truesize effects, posting large (e.g, PAGE_SIZE) buffers reduces the throughput of workloads that do not benefit from GRO and have no large inbound packets. This

The virtio-net device currently uses aligned MTU-sized mergeable receive packet buffers. Network throughput for workloads with large average packet size can be improved by posting larger receive packet buffers. However, due to SKB truesize effects, posting large (e.g, PAGE_SIZE) buffers reduces the throughput of workloads that do not benefit from GRO and have no large inbound packets. This