If there are more than one RX or TX threads, then make the name
of each of them unique so that it is easier to figure them out
in "kernel stacks" command.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The "tc" field which was holding the traffic class thread
priority is not used nor needed so remove it from the struct
to save some space.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Collect information how long net_pkt has travelled in IP stack
in certain points. See network documentation what these points
are and how to get information about the timings. This initial
commit adds support to TX timing collection.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Replace all occurences of BUILD_ASSERT_MSG() with BUILD_ASSERT()
as a result of merging BUILD_ASSERT() and BUILD_ASSERT_MSG().
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
We need to know whether the net_pkt was successfully placed
to transmit queue. It is possible in TX side, that the net_pkt
is already in TX queue when for example TCP packet is
re-transmitted, in which case the queue submit will fail.
This cannot happen in RX side as there are no timers involved.
It is required to check about such pending flag before trying to submit
it into the queue. Indeed, the work queue could be scheduled right after
such queuing, thus checking for the pending flag afterwards would
provide a false information.
It is unfortunate k_work_submit_to_queue() does not return anything as
it would simplify the code then.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This reverts commit 8739517107.
Pull Request #23437 was merged by mistake with an invalid manifest.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Replace all occurences of BUILD_ASSERT_MSG() with BUILD_ASSERT()
as a result of merging BUILD_ASSERT() and BUILD_ASSERT_MSG().
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
The current design of the network-specific stack dumping APIs
is fundamentally unsafe. You cannot properly dump stack data
without information which is only available in the thread object.
In addition, this infrastructure is unnecessary. There is already
a core shell command which dumps stack information for all
active threads.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Remove network specific default and max log level setting
and start to use the zephyr logging values for those.
Remove LOG_MODULE_REGISTER() from net_core.h and place the
calls into .c files. This is done in order to avoid weird
compiler errors in some cases and to make the code look similar
as other subsystems.
Fixes#11343Fixes#11659
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Instead of one global log level option and one on/off boolean
config option / module, this commit creates one log level option
for each module. This simplifies the logging as it is now possible
to enable different level of debugging output for each network
module individually.
The commit also converts the code to use the new logger
instead of the old sys_log.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This commits adds new priority to traffic class mappings and allows
users to choose which mapping to use through menuconfig.
The new mappings are recommended in 802.1 (chapter 34.5) for
time-sensitive applications supporting the credit-based sharper
algorithm.
Signed-off-by: Tomasz Gorochowik <tgorochowik@antmicro.com>
We init the net_tc tx/rx work queues during net_init() with a
call to init_rx_queues(). The L2/L3 and networking drivers have been
setup at this point. If we yield the current thread, we risk
a call to net_recv_data() which calls net_queue_rx() which calls
net_tc_submit_to_rx_queue() on an RX work queue which hasn't been
setup yet.
This manifests as a boot hang under seemingly random circumstances.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
The IEEE 802.1Q chapter I.3 contains a proper network packet
priority to traffic class mapping. The original mapping was
clearly incorrect.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Instead of one global statistics, collect statistics information
separately for each network interface. This per interface statistics
collection is optional but turned on by default. It can be turned
off if needed, in which case only global statistics are collected.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
As the priority currently fits u8_t then use it instead of int
for priority value for queue and thread.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The array size checks were incorrect.
Coverity-CID: 183482
Coverity-CID: 183485
Fixes#6883Fixes#6885
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Add statistics for number of packets and bytes to each traffic
class. Print this information in net-shell.
Also make sure that we do not calculate total packet length many
times. So calculate network packet total length once and then use
that value instead of calculating it many times in a row.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
With this commit it is possible to add priority to sent or received
network packets. So user is able to send or receive higher priority
packets faster than lower level packets.
The traffic class support is activated by CONFIG_NET_TC_COUNT option.
The TC support uses work queues to separate the traffic. The
priority of the work queue thread specifies the ordering of the
network traffic. Each work queue thread handles traffic to one specific
work queue. Note that you should not enable traffic classes unless
you really need them by your application. Each TC thread needs
stack so this feature requires more memory.
It is possible to disable transmit traffic class support and keep the
receive traffic class support, or vice versa. If both RX and TX traffic
classes are enabled, then both will use the same number of queues
defined by CONFIG_NET_TC_COUNT option.
Fixes#6588
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
