ed616689a3d95eb6c9bdbb1ef74b0f50cbdf276a |
|
22-May-2014 |
Sucheta Chakraborty <sucheta.chakraborty@qlogic.com> |
net-next:v4: Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool. o min_tx_rate puts lower limit on the VF bandwidth. VF is guaranteed to have a bandwidth of at least this value. max_tx_rate puts cap on the VF bandwidth. VF can have a bandwidth of up to this value. o A new handler set_vf_rate for attr IFLA_VF_RATE has been introduced which takes 4 arguments: netdev, VF number, min_tx_rate, max_tx_rate o ndo_set_vf_rate replaces ndo_set_vf_tx_rate handler. o Drivers that currently implement ndo_set_vf_tx_rate should now call ndo_set_vf_rate instead and reject attempt to set a minimum bandwidth greater than 0 for IFLA_VF_TX_RATE when IFLA_VF_RATE is not yet implemented by driver. o If user enters only one of either min_tx_rate or max_tx_rate, then, userland should read back the other value from driver and set both for IFLA_VF_RATE. Drivers that have not yet implemented IFLA_VF_RATE should always return min_tx_rate as 0 when read from ip tool. o If both IFLA_VF_TX_RATE and IFLA_VF_RATE options are specified, then IFLA_VF_RATE should override. o Idea is to have consistent display of rate values to user. o Usage example: - ./ip link set p4p1 vf 0 rate 900 ./ip link show p4p1 32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 900 (Mbps), max_tx_rate 900Mbps vf 1 MAC f6:c6:7c:3f:3d:6c vf 2 MAC 56:32:43:98:d7:71 vf 3 MAC d6:be:c3:b5:85:ff vf 4 MAC ee:a9:9a:1e:19:14 vf 5 MAC 4a:d0:4c:07:52:18 vf 6 MAC 3a:76:44:93:62:f9 vf 7 MAC 82:e9:e7:e3:15:1a ./ip link set p4p1 vf 0 max_tx_rate 300 min_tx_rate 200 ./ip link show p4p1 32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 300 (Mbps), max_tx_rate 300Mbps, min_tx_rate 200Mbps vf 1 MAC f6:c6:7c:3f:3d:6c vf 2 MAC 56:32:43:98:d7:71 vf 3 MAC d6:be:c3:b5:85:ff vf 4 MAC ee:a9:9a:1e:19:14 vf 5 MAC 4a:d0:4c:07:52:18 vf 6 MAC 3a:76:44:93:62:f9 vf 7 MAC 82:e9:e7:e3:15:1a ./ip link set p4p1 vf 0 max_tx_rate 600 rate 300 ./ip link show p4p1 32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 00:0e:1e:08:b0:f brd ff:ff:ff:ff:ff:ff vf 0 MAC 3e:a0:ca:bd:ae:5, tx rate 600 (Mbps), max_tx_rate 600Mbps, min_tx_rate 200Mbps vf 1 MAC f6:c6:7c:3f:3d:6c vf 2 MAC 56:32:43:98:d7:71 vf 3 MAC d6:be:c3:b5:85:ff vf 4 MAC ee:a9:9a:1e:19:14 vf 5 MAC 4a:d0:4c:07:52:18 vf 6 MAC 3a:76:44:93:62:f9 vf 7 MAC 82:e9:e7:e3:15:1a Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
cd84ff4da1f46cbdc2d73366eabe9a8f818447cd |
|
07-Mar-2014 |
Edward Cree <ecree@solarflare.com> |
sfc: Use ether_addr_copy and eth_broadcast_addr Faster than memcpy/memset on some architectures. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
f7a6d2c4427790cc8695401576dc594fcce8fc80 |
|
30-Aug-2013 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Update copyright banners Update the dates for files that have been added to in 2012-2013. Drop the 'Solarstorm' brand name that's still lingering here. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
86094f7f38ff711f3db8497fcb4d2e109100f497 |
|
21-Aug-2013 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Move and rename Falcon/Siena common NIC operations Add efx_nic_type operations for the many efx_nic functions that need to be implemented different on EF10. For now, change most of the existing efx_nic_*() functions into inline wrappers. As a later step, we may be able to improve branch prediction for operations used on the fast path by copying the pointers into each queue/channel structure. Move the Falcon/Siena implementations to new file farch.c and rename the functions and static data to use a prefix of 'efx_farch_'. Move efx_may_push_tx_desc() to nic.h, as the EF10 TX code will also use it. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
8b8a95a11aa985b7f6f6df8a0ffa597e56ff8310 |
|
18-Sep-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Rename Falcon-architecture register definitions The EF10 architecture has a very different register layout from previous controllers, so we'll use separate files for the two sets of register definitions. Use 'farch' as an abbreviation for Falcon-architecture. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
0d19a540beb78493cd5acb7428760af0dc1ea154 |
|
18-Sep-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Add GFP flags to efx_nic_alloc_buffer() and make most callers allow blocking Most call sites for efx_nic_alloc_buffer() are part of the probe or reconfiguration paths and can allocate with GFP_KERNEL. A few others should use GFP_NOIO (I think). Only one is in atomic context and must use the current GFP_ATOMIC. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
338f74df399d652788cf3bab247257ae90419c7d |
|
11-Oct-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Add and use MCDI_SET_QWORD() and MCDI_SET_ARRAY_QWORD() No need to keep open-coding the assignment of high and low dwords. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
c5bb0e9891ba1f7c871adc09d9ef727e1c0c1c1e |
|
14-Sep-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Use proper macros to declare and access MCDI arrays A few functions are using heap buffers; change them to use stack buffers as we really don't need to resort to the heap for a 252 byte buffer in process context. MC_CMD_MEMCPY is quite weird in that it can use inline data placed in the request buffer after the array of records. Thus there are two variable-length arrays and we can't use the normal accessors for the second. So we have to use _MCDI_PTR() in efx_sriov_memcpy(). Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
d0c2ee99e54c0fd76938236e863ad7d3992f044f |
|
20-Aug-2013 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Introduce and use MCDI_CTL_SDU_LEN_MAX_V1 macro for Siena-specific code The MCDI version 2 protocol supports larger payloads, but will not be implemented on Siena. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
59cfc479b2c8ba344c8497d5c913b6cba2ce3755 |
|
14-Sep-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Introduce and use MCDI_DECLARE_BUF macro MCDI_DECLARE_BUF declares a variable as an MCDI buffer of the requested length, adding any necessary padding. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
778cdaf639e34288c298f1d3d3503d0724ceabc7 |
|
18-Sep-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Remove confusing MMIO functions efx_writed_table() uses a step of 16 bytes but efx_readd_table() uses a step of 4 bytes. Why are they different? Firstly, register access is asymmetric: - The EVQ_RPTR table and RX_INDIRECTION_TBL can (or must?) be written as dwords even though they have a step size of 16 bytes, unlike most other CSRs. - In general, a read of any width is valid for registers, so long as it does not cross register boundaries. There is also no latching behaviour in the BIU, contrary to rumour. We write to the EVQ_RPTR table with efx_writed_table() but never read it back as it's write-only. We write to the RX_INDIRECTION_TBL with efx_writed_table(), but only read it back for the register dump, where we use efx_reado_table() as for any other table with step size of 16. We read MC_TREG_SMEM with efx_readd_table() for the register dump, but normally read and write it with efx_readd() and efx_writed() using offsets calculated in bytes. Since these functions are trivial and have few callers, it's clearer to open-code them at the call sites. While we're at it, update the comments on the BIU behaviour again. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
d5e8cc6c946e0857826dcfbb3585068858445bfe |
|
06-Sep-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Really disable flow control while flushing Receiving pause frames can block TX queue flushes. Earlier changes work around this by reconfiguring the MAC during flushes for VFs, but during flushes for the PF we would only change the fc_disable counter. Unless the MAC is reconfigured for some other reason during the flush (which I would not expect to happen) this had no effect at all. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
726ba0e14a7915effee9e8e652a37306d9637d13 |
|
02-Oct-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Fix null function pointer in efx_sriov_channel_type Commit c31e5f9 ('sfc: Add channel specific receive_skb handler and post_remove callback') added the function pointer field efx_channel_type::post_remove and an unconditional call through it. This field should have been initialised to efx_channel_dummy_op_void in the existing instances of efx_channel_type, but this was only done in efx_default_channel_type. Consequently, if a device has SR-IOV enabled then removing the driver or device will result in an oops. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
450783747f42dfa3883920acfad4acdd93ce69af |
|
19-Sep-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Avoid generating over-length MC_CMD_FLUSH_RX_QUEUES request MCDI supports requests up to 252 bytes long, which is only enough to pass 63 RX queue IDs to MC_CMD_FLUSH_RX_QUEUES. However a VF may have up to 64 RX queues, and if we try to flush them all we will generate an over-length request and BUG() in efx_mcdi_copyin(). Currently all VF drivers limit themselves to 32 RX queues, so reducing the limit to 63 does no harm. Also add a BUILD_BUG_ON in efx_mcdi_flush_rxqs() so we remember to deal with the same problem there if EFX_MAX_CHANNELS is increased. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
2c61c8a787fc3382edefd8c7ad3e0f74c81e5302 |
|
02-Mar-2012 |
Robert Stonehouse <rstonehouse@solarflare.com> |
sfc: Fix calculation of vf_i in map_vi_index() This was broken during refactoring to use efx_vf_size(). [bwh: Keep using efx_vf_size()] Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
01cb543db8a2d2dbcea5f357365ce1327ac46193 |
|
21-Feb-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Correct validation of peer_page_count in efx_vfdi_set_status_page() efx_vfdi_set_status_page() validates the peer page count by calculating the size of a request containing that many addresses and comparing that with the maximum valid request size (4KB). The calculation involves a multiplication that may overflow on a 32-bit system. We use kcalloc() to allocate memory to store the addresses; that also does a multiplication and it does check for integer overflow, so any values larger than 0x1fffffff will be rejected. However, values in the range [0x1fffffffc, 0x1fffffff] pass boh tests and result in an attempt to allocate nearly 4GB on the heap. This should be rejected rather quickly as it's obviously impossible on a 32-bit system, and indeed the maximum possible heap allocation is 32MB. Still, let's make absolutely sure by fixing the initial validation. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|
cd2d5b529cdb9bd274f3e4bc68d37d4d63b7f383 |
|
14-Feb-2012 |
Ben Hutchings <bhutchings@solarflare.com> |
sfc: Add SR-IOV back-end support for SFC9000 family On the SFC9000 family, each port has 1024 Virtual Interfaces (VIs), each with an RX queue, a TX queue, an event queue and a mailbox register. These may be assigned to up to 127 SR-IOV virtual functions per port, with up to 64 VIs per VF. We allocate an extra channel (IRQ and event queue only) to receive requests from VF drivers. There is a per-port limit of 4 concurrent RX queue flushes, and queue flushes may be initiated by the MC in response to a Function Level Reset (FLR) of a VF. Therefore, when SR-IOV is in use, we submit all flush requests via the MC. The RSS indirection table is shared with VFs, so the number of RX queues used in the PF is limited to the number of VIs per VF. This is almost entirely the work of Steve Hodgson, formerly shodgson@solarflare.com. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
|