This doesn't include the same kind of userland overriding that the IPv4
path has; nor does it yet know about 2-tuple versus 4-tuple hashing.
That'll come later.
Differential Revision: https://reviews.freebsd.org/D527
Reviewed by: grehan
with no RSS hash.
When doing RSS:
* Create a new IPv4 netisr which expects the frames to have been verified;
it just directly dispatches to the IPv4 input path.
* Once IPv4 reassembly is done, re-calculate the RSS hash with the new
IP and L3 header; then reinject it as appropriate.
* Update the IPv4 netisr to be a CPU affinity netisr with the RSS hash
function (rss_soft_m2cpuid) - this will do a software hash if the
hardware doesn't provide one.
NICs that don't implement hardware RSS hashing will now benefit from RSS
distribution - it'll inject into the correct destination netisr.
Note: the netisr distribution doesn't work out of the box - netisr doesn't
query RSS for how many CPUs and the affinity setup. Yes, netisr likely
shouldn't really be doing CPU stuff anymore and should be "some kind of
'thing' that is a workqueue that may or may not have any CPU affinity";
that's for a later commit.
Differential Revision: https://reviews.freebsd.org/D527
Reviewed by: grehan
and egress.
* rss_mbuf_software_hash_v4 - look at the IPv4 mbuf to fetch the IPv4 details
+ direction to calculate a hash.
* rss_proto_software_hash_v4 - hash the given source/destination IPv4 address,
port and direction.
* rss_soft_m2cpuid - map the given mbuf to an RSS CPU ("bucket" for now)
These functions are intended to be used by the stack to support
the following:
* Not all NICs do RSS hashing, so we should support some way of doing
a hash in software;
* The NIC / driver may not hash frames the way we want (eg UDP 4-tuple
hashing when the stack is only doing 2-tuple hashing for UDP); so we
may need to re-hash frames;
* .. same with IPv4 fragments - they will need to be re-hashed after
reassembly;
* .. and same with things like IP tunneling and such;
* The transmit path for things like UDP, RAW and ICMP don't currently
have any RSS information attached to them - so they'll need an
RSS calculation performed before transmit.
TODO:
* Counters! Everywhere!
* Add a debug mode that software hashes received frames and compares them
to the hardware hash provided by the hardware to ensure they match.
The IPv6 part of this is missing - I'm going to do some re-juggling of
where various parts of the RSS framework live before I add the IPv6
code (read: the IPv6 code is going to go into netinet6/in6_rss.[ch],
rather than living here.)
Note: This API is still fluid. Please keep that in mind.
Differential Revision: https://reviews.freebsd.org/D527
Reviewed by: grehan
information as part of recvmsg().
This is primarily used for debugging/verification of the various
processing paths in the IP, PCB and driver layers.
Unfortunately the current implementation of the control message path
results in a ~10% or so drop in UDP frame throughput when it's used.
Differential Revision: https://reviews.freebsd.org/D527
Reviewed by: grehan
overriding an existing flowid/flowtype field in the outbound mbuf with
the inp_flowid/inp_flowtype details.
The upcoming RSS UDP support calculates a valid RSS value for outbound
mbufs and since it may change per send, it doesn't cache it in the inpcb.
So overriding it here would be wrong.
Differential Revision: https://reviews.freebsd.org/D527
Reviewed by: grehan
u-boot env into the loader(8) env (which also gets them into the kernel
env). You can import selected variables or the whole environment. Each
u-boot var=value becomes uboot.var=value in the loader env. You can also
use 'ubenv show' to display uboot vars without importing them.
This fixes a panic in the i915 driver when one uses debug.kdb.enter=1
under vt(4).
PR: 193269
Reported by: emaste@
Submitted by: avg@
MFC after: 3 days
This fixes a bug where scroll lock would not work for tty #0 when using
vt_vga's textmode. The reason was that this window is created with a
static 256x100 buffer, larger than the real size of 80x25.
Now, in vt_change_font() and vt_compute_drawable_area(), we still
perform operations even of the window has no font loaded (this is the
case in textmode here vw->vw_font == NULL). One of these operation
resizes the buffer accordingly.
In vt_compute_drawable_area(), we take the terminal size as is (ie.
80x25) for the drawable area.
The font argument to vt_set_border() is removed (it was never used) and
the code now uses the computed drawable area instead of re-doing its own
calculation.
Reported by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de>
Tested by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de>
MFC after: 3 days
The rules turn out to be:
* for non-aggregation session TX queues - it's either sent or not sent.
* for aggregation session TX queues - if nframes=1, then the status reflects
the completed transmission.
* however, for nframes > 1, then this is just a status reflecting what
the initial transmission did. The compressed BA (immediate or delayed)
may not have yet been received, so the actual frame status is in the
compressed BA updates.
Whilst here, I fiddled with debugging and formatting a bit.
There's also RTS attempts (what the atheros chips call "short retries")
which weren't being logged and they aren't yet being used in the rate
control statistics updates. For now, at least log them.
TODO:
* This still isn't 100% correct! So I have to tinker with this some more.
(The failures aren't always failures..)
* Extend the rate control API in net80211 so it can take both short and
long retry counts.
Tested:
* Intel 5100, STA mode
The (eventual) intention is to create MIB counters for transmitted
frame completion to count how many packets with each status are
transmitted.
Note the difference between A-MPDU and non A-MPDU status.
Obtained from: Linux iwlwifi/dvm driver
va == pa map.
I'm not sure the code would work if we are not running from the identity
map as the ARM core may attempt to read the next instruction from an
invalid memory location.
In dnode_sync(), do dnode_increase_indirection() before processing
the dn_next_nblkptr.
Illumos issue:
5117 space map reallocation can cause corruption
MFC after: 3 days
eliminiates some warnings when building in userland.
Thanks to Patrick Laimbock for reporting this issue.
Remove also some unnecessary casts.
There should be no functional change.
MFC after: 1 week
boards.
This is just intended to split the common config entries out, further
cleanup is expected.
Reviewed by: ian@, rpaulo@ (earlier version)
Differential Revision: https://reviews.freebsd.org/D731
For controllers with only one port (like PCIe or M.2 SSDs) interrupt can
come from only one source, and skipping read saves few percents of CPU time.
MFC after: 1 month
H/W donated by: I/O Switch
It is the compaction bitmask, with the highest bit defining if compact
format of the xsave area is used at all.
Adjust the definition of struct xstate_hdr, provide define for bit 63.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
an entry in the xref list if one doesn't already exist for the given handle.
On a system that uses phandle properties, the init-time scan of the tree
which builds the xref list will pre-create entries for every xref handle
that exists in the data. On systems where the xref and node handles are
synonymous there is no phandle property in referenced nodes, and the xref
list will initialize to an empty state. In the latter case, we still need
to be able to associate a device_t with an xref handle, so we create list
entries on the fly as needed. Since the node and xref handles are
synonymous, we have all the info needed to create a list entry at device
registration time.
The downside to this change is that it basically allows on the fly creation
of xref handles as synonyms of node handles, and the association of a
device_t with them. Whether this is a bug or a feature is in the eye of
the beholder, I guess.
o Unmagic 'configuration done' bit
o Move probe() to place before attach() for better navigation
o Use bus_read_n instead of bus_space_read_n functions
Pointed out by: andrew
Sponsored by: DARPA, AFRL
%eax report.
Print the XSAVE features 0xd/1 in the boot banner. The printcpuinfo()
is executed late enough so that XSAVE is already enabled.
There is no known to me off the shelf hardware that implements any
feature bits except XSAVEOPT, the list is taken from SDM rev. 50. The
banner printing will allow us to note the hardware arrival.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
resume that is a superset of a pcb. Move the FPU state out of the pcb and
into this new structure. As part of this, move the FPU resume code on
amd64 into a C function. This allows resumectx() to still operate only on
a pcb and more closely mirrors the i386 code.
Reviewed by: kib (earlier version)
for the node. The default routine returns the untranslated handle, which
is sometimes useful, but sometimes you really need to know there's no
entry in the xref<->node<->device translation table.
be usable as the default timer in place of the physical timer.
We are guaranteed to have access to the virtual timer, but when running
under a hypervisor may not have access to the physical.
Differential Revision: https://reviews.freebsd.org/D588
