netdev - Re: [net-next-2.6 PATCH v5 1/2] net: implement mechanism for HW based QOS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1294338015.11825.26.camel@bwh-desktop>
Date:	Thu, 06 Jan 2011 18:20:15 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	John Fastabend <john.r.fastabend@...el.com>, eric.dumazet@...il.com
Cc:	davem@...emloft.net, jarkao2@...il.com, hadi@...erus.ca,
	shemminger@...tta.com, tgraf@...radead.org, nhorman@...driver.com,
	netdev@...r.kernel.org
Subject: Re: [net-next-2.6 PATCH v5 1/2] net: implement mechanism for HW
 based QOS

On Tue, 2011-01-04 at 10:56 -0800, John Fastabend wrote:
[...]
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 0f6b1c9..ae51323 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -646,6 +646,14 @@ struct xps_dev_maps {
>      (nr_cpu_ids * sizeof(struct xps_map *)))
>  #endif /* CONFIG_XPS */
>  
> +#define TC_MAX_QUEUE	16
> +#define TC_BITMASK	15
> +/* HW offloaded queuing disciplines txq count and offset maps */
> +struct netdev_tc_txq {
> +	u16 count;
> +	u16 offset;
> +};
> +
>  /*
>   * This structure defines the management hooks for network devices.
>   * The following hooks can be defined; unless noted otherwise, they are
> @@ -1146,6 +1154,9 @@ struct net_device {
>  	/* Data Center Bridging netlink ops */
>  	const struct dcbnl_rtnl_ops *dcbnl_ops;
>  #endif
> +	u8 num_tc;
> +	struct netdev_tc_txq tc_to_txq[TC_MAX_QUEUE];
> +	u8 prio_tc_map[TC_BITMASK+1];
[...]

I'm still concerned by the addition of all this state to every
net_device.  From previous discussion, Eric wanted this, citing 'false
sharing' while Stephen thought it should be accessed indirectly.

Eric, when you refer to 'false sharing' do you mean that the TC state
might end up sharing a cache line with some other data?  That seems
quite unlikely as the allocation size will be 128 bytes, and it could be
padded to fill a cache line if that's still a concern.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html