CXGBETOOL(8) | MidnightBSD System Manager's Manual | CXGBETOOL(8) |
cxgbetool
—
Userspace companion to
cxgbe(4)
cxgbetool nexus command
[parameter ...] |
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
{ |
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool nexus
|
cxgbetool
provides command-line access to
features and debug facilities exported by
cxgbe(4) via private
ioctls. The target nexus device, t4nex%d , is always
the first argument. (The parent nexus for an Ethernet port
cxgbe%d is listed in
dev.cxgbe.%d.%parent in the
sysctl(8) MIB). The rest
consists of a command and any parameters required by that command.
clearstats
port_idcontext
ingress
ingress_cntxt_idcontext
cong
ingress_cntxt_idcontext
egress
egress_cntxt_idcontext
fl
flm_cntxt_id(Note that mask defaults to all 1s when not provided explicitly. Hash filters do not support masked matches. Also note that many of the items being matched are discrete numeric values rather than bit fields and should be masked with caution.)
Criteria | Usage | Matches if ... |
ipv4 | type ipv4 | incoming packet is an IPv4 datagram. |
ipv6 | type ipv6 | incoming packet is an IPv6 datagram. |
sip | sip Ar addr Ns Op / Ns Ar mask | bitwise and of the source address in an incoming IP datagram with mask equals addr Ns . addr can be an IPv4 or IPv6 address. |
dip | dip Ar addr Ns Op / Ns Ar mask | bitwise and of the destination address in an incoming IP datagram with mask equals addr Ns . addr can be an IPv4 or IPv6 address. |
sport | sport Ar port Ns Op : Ns Ar mask | bitwise and of the source port in an incoming TCP or UDP datagram with mask equals port Ns . |
dport | dport Ar port Ns Op : Ns Ar mask | bitwise and of the destination port in an incoming TCP or UDP datagram with mask equals port Ns . |
fcoe | fcoe Brq 0 | 1 | incoming frame is Fibre Channel over Ethernet(1) or not(0). |
iport | iport Ar val Ns Op : Ns Ar mask | bitwise and of the ingress port with mask equals val Ns . The ingress port is a 3 bit number that identifies the port on which a frame arrived. Physical ports are numbered 0-3 and 4-7 are internal loopback paths within the chip. Note that ingress port is not a bit field so it is not always possible to match an arbitrary subset of ingress ports with a single filter rule. |
ovlan | ovlan Ar tag Ns Op : Ns Ar mask | bitwise and of the 16-bit outer VLAN tag of an incoming frame with mask equals tag Ns . |
vlan | vlan Ar tag Ns Op : Ns Ar mask | bitwise and of the 16-bit VLAN tag of an incoming QinQ frame with mask equals tag Ns . The inner VLAN tag is used if the incoming frame is QinQ. |
tos | tos Ar val Ns Op : Ns Ar mask | bitwise and of the 8-bit IP Type of Service/IPv6 Traffic Class in an incoming packet with mask equals val Ns . |
proto | proto Ar ipproto Ns Op : Ns Ar mask | bitwise and of the 8-bit IP protocol in an incoming packet with mask equals ipproto Ns . |
ethtype | ethtype Ar type Ns Op : Ns Ar mask | bitwise and of the 16-bit Ethernet type field of an incoming frame with mask equals type Ns . |
macidx | macidx Ar idx Ns Op : Ns Ar mask | bitwise and of the MAC Address Match Index of an incoming frame with mask equals idx Ns . The MAC Address Match Index refers to an entry in the MPS TCAM or in the MPS hash. See matchtype for more information. |
matchtype | matchtype Ar type Ns Op : Ns Ar mask | bitwise and of the Match Type of an incoming frame with mask equals idx Ns . Match Type is one of the following: -tag -width "n" -compact 0 destination MAC in incoming frame is a unicast L2 address that is programmed in the MPS TCAM. macidx can be used to match the index (and thus the MAC address) of the match in the TCAM. 1 destination MAC in incoming frame is a unicast L2 address that "hit" a hash entry in the MPS hash table. macidx can be used to match the index of the entry in the MPS hash table. 2 destination MAC in incoming frame is a multicast L2 address that is programmed in the MPS TCAM. macidx can be used to match the index (and thus the MAC address) of the match in the TCAM. 3 destination MAC in incoming frame is a multicast L2 address that "hit" an entry in the MPS hash table. 4 interface on which incoming frame was received is in promiscuous mode and the destination MAC in the frame is not a broadcast address, and does not match in the MPS TCAM or the MPS hash either. (The frame would have been discarded if the interface wasn't in promiscuous mode.) 5 interface on which incoming frame was received is in promiscuous mode and the destination MAC in the frame is not a broadcast address; it wasn't looked up in the MPS TCAM or the MPS hash because the chip is configured to give precedence to promiscuous mode classification. 6 destination MAC in incoming frame is a broadcast address. 7 Not documented. Do not use. |
frag | frag Brq 0 | 1 | incoming frame is part of a fragmented IP datagram(1) or not(0). |
hashfilter
filter-specificationfilter
idx
filter-specificationTCAM filters: The number of available filters is in dev.<nexus>.<instance>.nfilters. idx must be an unused index between 0 and nfilters - 1. IPv6 filters consume 4 consecutive entries on T4/T5 and 2 on T6 and idx must be aligned to 4 or 2 in this case.
Hash filters: These reside in the card's memory instead of its
TCAM and are enabled with a special configuration file that is selected
with hw.cxgbe.config_file="hashfilter"
in loader.conf. There are at least half a million filters available with
the sample config shipped with the driver. Note that the hardware
selects the index for a hashfilter and this index is displayed when the
filter is created. Hash and TCAM filters can be used together.
filter-specification consists of one or
more matches (see Usage in the table above) to try against an incoming
frame, an action to perform when all matches succeed, and some
additional operational parameters. Hashfilters require an exact value
for the 5-tuple (sip, dip, sport, dport, proto) and for any other
match-criteria listed in "hashfilter mode". Possible filter
actions are drop
, pass
,
or switch
.
Operational parameters that can be used with all filters:
Operational parameters that can be used with filters with
action pass
:
queue
rpttid
tcbhash
Operational parameters that can be used with filters with
action switch
:
eport
dmac
smac
swapmac
vlan
none
removes the tag,
=
tag replaces the
existing tag with the one provided, and
+
tag inserts the given
tag into the frame.nat
dip
dip-dp
dip-dp-sip
dip-dp-sp
sip-sp
dip-sip-sp
all
natflag
natseq
nat_dip
nat_sip
nat_dport
nat_sport
hashfilter
idx delete
filter
idx delete
filter
list
i2c
port_id devaddr addr [len]loadcfg
fw-config.txtloadcfg
clear
loadfw
fw-image.binmemdump
addr lenpolicy
cop.txthw.cxgbe.cop_managed_offloading="1"
in
loader.conf to ensure that t4_tom will not offload any connection before a
COP is installed. Note that t4_tom must be loaded and operational
(IFCAP_TOE enabled) as always for any kind of offload based on the
hardware TOE.
COP installed | cop_managed_offloading | Behavior |
NO | 0 | offload all [Default] |
NO | 1 | no offload |
YES | Don't Care | Rule based offload |
The policy file consists of empty lines, comments (lines beginning with #) and any number of rules. Rules are applied in the order they appear in the file and processing stops at the first match. There is an implicit rule that disables offload for connections that do not match anything in the policy.
Each rule consists of a filter part, which determines what connections the rule applies to, and a settings part, which determines whether matching connections will be offloaded and, if so, with what settings. The general form of a rule is
[
socket-type ]
pcap-filter =>
settingssocket-type is one of the following.
pcap-filter is an expression that
follows the
pcap-filter(7)
syntax, or it is the keyword all
that
matches everything.
settings determine whether connections matching socket-type and pcap-filter are offloaded and optionally sets some per-connection properties if they are. A combination of the following is allowed.
offload
!offload
or not
offload
to disable offload instead.coalesce
timestamp
sack
nagle
ecn
ddp
tls
cong
algoreno
, tahoe
,
newreno
, or
highspeed
.class
scrxq
qidtxq
qnumbind
qnumrxq
qnum txq
qnum. Use only when nofldrxq is the same as
nofldtxq.mss
val[L] port 80 => offload [L] port 443 => offload [L] ip6 => !offload [L] port 22 => offload [P] dst port 80 => offload cong highspeed !sack !ecn [P] dst port 443 => offload tls [A] dst net 192.168/16 => offload [A] all => !offload [D] port 22 => offload !nagle
policy
clear
reg
| reg64
}
addr[=val]regdump
[register-block ...]regdump
operation.
register-block can be sge pci dbg
mc ma edc0 edc1 cim tp ulp_rx ulp_tx pmrx pmtx mps cplsw
smb i2c mi uart pmu sf pl le ncsi xgmac
.sched-class
config
[param
value]NOTE: Many (most) of the parameters and constraints are adapter-specific - for instance the number of channels and classes which are available whether various modes are implemented, etc. Consult the adapter documentation for specific information on any limitations.
sched-class
params
[param
value]E.g. if the scheduling class has a TX bandwidth of 10Mb/s,
in class
mode, all of the "flows"
bound to the class would be limited to an aggregate bandwidth of
10Mb/s; but in flow
mode, each of the
"flows" bound to the scheduling class would be limited to
10Mb/s.
NOTE: Many (most) of the parameters and constraints are adapter-specific - for instance the number of channels and classes which are available, whether various modes are implemented, etc. Consult the adapter documentation for specific information on any limitations.
sched-queue
port queue classall, *
or any
negative value, the binding will apply to all of the TX queues associated
with the interface. If the class is
unbind, clear
or any negative value, the TX
queue(s) will be unbound from any current TX Scheduler Class binding.stdio
tcb
tid/sys/dev/cxgbe/t4_ioctl.h
This manual page was written by Navdeep Parhar ⟨np@FreeBSD.org⟩.
September 21, 2018 | midnightbsd-3.1 |