Searched hist:"65870 fa7" (Results 1 – 1 of 1) sorted by relevance
/openbmc/linux/drivers/net/ethernet/broadcom/bnx2x/ |
H A D | bnx2x_ethtool.c | 65870fa7 Sun Dec 04 07:30:17 CST 2016 Mintz, Yuval <Yuval.Mintz@cavium.com> bnx2x: Correct ringparam estimate when DOWN
Until interface is up [and assuming ringparams weren't explicitly configured] when queried for the size of its rings bnx2x would claim they're the maximal size by default. That is incorrect as by default the maximal number of buffers would be equally divided between the various rx rings.
This prevents the user from actually setting the number of elements on each rx ring to be of maximal size prior to transitioning the interface into up state.
To fix this, make a rough estimation about the number of buffers. It wouldn't always be accurate, but it would be much better than current estimation and would allow users to increase number of buffers during early initialization of the interface.
Reported-by: Seymour, Shane <shane.seymour@hpe.com> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net> 65870fa7 Sun Dec 04 07:30:17 CST 2016 Mintz, Yuval <Yuval.Mintz@cavium.com> bnx2x: Correct ringparam estimate when DOWN Until interface is up [and assuming ringparams weren't explicitly configured] when queried for the size of its rings bnx2x would claim they're the maximal size by default. That is incorrect as by default the maximal number of buffers would be equally divided between the various rx rings. This prevents the user from actually setting the number of elements on each rx ring to be of maximal size prior to transitioning the interface into up state. To fix this, make a rough estimation about the number of buffers. It wouldn't always be accurate, but it would be much better than current estimation and would allow users to increase number of buffers during early initialization of the interface. Reported-by: Seymour, Shane <shane.seymour@hpe.com> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|