eb8e81ad0d
A step toward having multi-Txq support on same queue-zone for VFs. This change takes care of: - VFs assume a single CID per-queue, where queue X receives CID X. Switch to a model similar to that of PF - I.e., Use different CIDs for Rx/Tx, and use mapping to acquire/release those. Each VF currently will have 32 CIDs available for it [for its possible 16 Rx & 16 Tx queues]. - To retain the same interface for PFs/VFs when initializing queues, the base driver would have to retain a unique number per-each queue that would be communicated in some extended TLV [current TLV interface allows the PF to send only the queue-id]. The new TLV isn't part of the current change but base driver would now start adding such unique keys internally to queue_cids. This would also force us to start having alloc/setup/free for L2 [we've refrained from doing so until now] The limit would be no-more than 64 queues per qzone [This could be changed if needed, but hopefully no one needs so many queues] - In IOV, Add infrastructure for up to 64 qids per-qzone, although at the moment hard-code '0' for Rx and '1' for Tx [Since VF still isn't communicating via new TLV which index to associate with a given queue in its queue-zone]. Signed-off-by: Rasesh Mody <rasesh.mody@cavium.com> |
||
---|---|---|
.. | ||
af_packet | ||
avp | ||
bnx2x | ||
bnxt | ||
bonding | ||
cxgbe | ||
e1000 | ||
ena | ||
enic | ||
fm10k | ||
i40e | ||
ixgbe | ||
kni | ||
liquidio | ||
mlx4 | ||
mlx5 | ||
nfp | ||
null | ||
pcap | ||
qede | ||
ring | ||
sfc | ||
szedata2 | ||
tap | ||
thunderx | ||
vhost | ||
virtio | ||
vmxnet3 | ||
xenvirt | ||
Makefile |