* Re: FW: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers [not found] <CFE9BFE80FFE4D4892AA5D31387E310F02F3ED@mtldag01.mtl.com> @ 2011-03-07 21:36 ` Eli Cohen 2011-03-07 21:40 ` David Miller 0 siblings, 1 reply; 7+ messages in thread From: Eli Cohen @ 2011-03-07 21:36 UTC (permalink / raw) To: roland, davem; +Cc: davem, netdev > > On Mon, Mar 7, 2011 at 2:17 AM, Yevgeny Petrilin > <yevgenyp@mellanox.co.il> wrote: > > + if (map_bf_area(dev)) > > + mlx4_dbg(dev, "Kernel support for blue flame is not available for kernels < 2.6.28\n"); > > This seems like a really bad error message. Can map_bf_area() actually fail? I agree that this message is inappropriate here; it is originiated from the OFED patches which support older kernels too. As for the question if a message is justified here at all, I think the answer is yes becuase of this: +static int map_bf_area(struct mlx4_dev *dev) +{ + struct mlx4_priv *priv = mlx4_priv(dev); + resource_size_t bf_start; + resource_size_t bf_len; + int err = 0; + + bf_start = pci_resource_start(dev->pdev, 2) + (dev->caps.num_uars << PAGE_SHIFT); + bf_len = pci_resource_len(dev->pdev, 2) - (dev->caps.num_uars << PAGE_SHIFT); + priv->bf_mapping = io_mapping_create_wc(bf_start, bf_len); + if (!priv->bf_mapping) + err = -ENOMEM; Specifically, some archs may not support write combining. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers 2011-03-07 21:36 ` FW: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers Eli Cohen @ 2011-03-07 21:40 ` David Miller 2011-03-07 21:48 ` Eli Cohen 0 siblings, 1 reply; 7+ messages in thread From: David Miller @ 2011-03-07 21:40 UTC (permalink / raw) To: eli; +Cc: roland, netdev From: Eli Cohen <eli@dev.mellanox.co.il> Date: Mon, 7 Mar 2011 23:36:48 +0200 > Specifically, some archs may not support write combining. They should just create a non-write-combining mapping if they don't support it. It could still fail due to resource constraints, but not because of the reason you're stating. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers 2011-03-07 21:40 ` David Miller @ 2011-03-07 21:48 ` Eli Cohen 2011-03-07 21:49 ` David Miller 0 siblings, 1 reply; 7+ messages in thread From: Eli Cohen @ 2011-03-07 21:48 UTC (permalink / raw) To: David Miller; +Cc: roland, netdev On Mon, Mar 07, 2011 at 01:40:01PM -0800, David Miller wrote: > From: Eli Cohen <eli@dev.mellanox.co.il> > Date: Mon, 7 Mar 2011 23:36:48 +0200 > > > Specifically, some archs may not support write combining. > > They should just create a non-write-combining mapping if they > don't support it. > I wouldn't expect that since the caller function could be mislead to believe it has a write combining capable area. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers 2011-03-07 21:48 ` Eli Cohen @ 2011-03-07 21:49 ` David Miller 2011-03-07 21:50 ` David Miller 2011-03-07 21:58 ` Eli Cohen 0 siblings, 2 replies; 7+ messages in thread From: David Miller @ 2011-03-07 21:49 UTC (permalink / raw) To: eli; +Cc: roland, netdev From: Eli Cohen <eli@dev.mellanox.co.il> Date: Mon, 7 Mar 2011 23:48:12 +0200 > On Mon, Mar 07, 2011 at 01:40:01PM -0800, David Miller wrote: >> From: Eli Cohen <eli@dev.mellanox.co.il> >> Date: Mon, 7 Mar 2011 23:36:48 +0200 >> >> > Specifically, some archs may not support write combining. >> >> They should just create a non-write-combining mapping if they >> don't support it. >> > > I wouldn't expect that since the caller function could be mislead to > believe it has a write combining capable area. It's a performance optimization, if you don't get write combining you'll get more strict ordering, rather than less. It cannot cause problem. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers 2011-03-07 21:49 ` David Miller @ 2011-03-07 21:50 ` David Miller 2011-03-07 21:58 ` Eli Cohen 1 sibling, 0 replies; 7+ messages in thread From: David Miller @ 2011-03-07 21:50 UTC (permalink / raw) To: eli; +Cc: roland, netdev From: David Miller <davem@davemloft.net> Date: Mon, 07 Mar 2011 13:49:31 -0800 (PST) > From: Eli Cohen <eli@dev.mellanox.co.il> > Date: Mon, 7 Mar 2011 23:48:12 +0200 > >> On Mon, Mar 07, 2011 at 01:40:01PM -0800, David Miller wrote: >>> From: Eli Cohen <eli@dev.mellanox.co.il> >>> Date: Mon, 7 Mar 2011 23:36:48 +0200 >>> >>> > Specifically, some archs may not support write combining. >>> >>> They should just create a non-write-combining mapping if they >>> don't support it. >>> >> >> I wouldn't expect that since the caller function could be mislead to >> believe it has a write combining capable area. > > It's a performance optimization, if you don't get write combining you'll > get more strict ordering, rather than less. > > It cannot cause problem. BTW, if we did as you suggest, fail if we don't support write combining, then half the drivers in the tree would fail to probe on sparc64. Every other driver expects it to succeed, with either write-combining or more strict ordering semantics. Never to fail simply because write-combining isn't supported. It's a request, not a requirement. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers 2011-03-07 21:49 ` David Miller 2011-03-07 21:50 ` David Miller @ 2011-03-07 21:58 ` Eli Cohen 2011-03-07 22:09 ` David Miller 1 sibling, 1 reply; 7+ messages in thread From: Eli Cohen @ 2011-03-07 21:58 UTC (permalink / raw) To: David Miller; +Cc: roland, netdev On Mon, Mar 07, 2011 at 01:49:31PM -0800, David Miller wrote: > > It's a performance optimization, if you don't get write combining you'll > get more strict ordering, rather than less. > > It cannot cause problem. I agree, but the function could still fail and the caller's logic could attempt to call ioreamp or take other action. For example, in the case of blue flame, it is better performance-wise to avoid using this feature if write combining is not available. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers 2011-03-07 21:58 ` Eli Cohen @ 2011-03-07 22:09 ` David Miller 0 siblings, 0 replies; 7+ messages in thread From: David Miller @ 2011-03-07 22:09 UTC (permalink / raw) To: eli; +Cc: roland, netdev From: Eli Cohen <eli@dev.mellanox.co.il> Date: Mon, 7 Mar 2011 23:58:03 +0200 > On Mon, Mar 07, 2011 at 01:49:31PM -0800, David Miller wrote: >> >> It's a performance optimization, if you don't get write combining you'll >> get more strict ordering, rather than less. >> >> It cannot cause problem. > > I agree, but the function could still fail and the caller's logic > could attempt to call ioreamp or take other action. For example, in > the case of blue flame, it is better performance-wise to avoid using > this feature if write combining is not available. It could, but the less complicated the interfaces the better. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-03-07 22:08 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CFE9BFE80FFE4D4892AA5D31387E310F02F3ED@mtldag01.mtl.com>
2011-03-07 21:36 ` FW: [PATCH 13/17] mlx4: Add blue flame support for kernel consumers Eli Cohen
2011-03-07 21:40 ` David Miller
2011-03-07 21:48 ` Eli Cohen
2011-03-07 21:49 ` David Miller
2011-03-07 21:50 ` David Miller
2011-03-07 21:58 ` Eli Cohen
2011-03-07 22:09 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).