Tue, Sep 29, 2020 at 03:57:00PM CEST, and...@lunn.ch wrote:
>On Tue, Sep 29, 2020 at 03:07:58PM +0200, Jiri Pirko wrote:
>> Tue, Sep 29, 2020 at 01:03:56PM CEST, vladimir.olt...@nxp.com wrote:
>> >On Mon, Sep 28, 2020 at 06:46:14PM -0700, Florian Fainelli wrote:
>> >> That makes sense to me as it w
On 9/29/2020 18:08, Kai-Heng Feng wrote:
Hello Kai-Heng,
On Sep 29, 2020, at 21:46, Neftin, Sasha wrote:
Hello Kai-Heng,
On 9/29/2020 16:31, Kai-Heng Feng wrote:
Hi Sasha,
On Sep 29, 2020, at 21:08, Neftin, Sasha wrote:
On 9/28/2020 11:36, Kai-Heng Feng wrote:
We are seeing the followi
Realtek single-chip Ethernet PHY solutions can be separated as below:
10M/100Mbps: RTL8201X
1Gbps: RTL8211X
2.5Gbps: RTL8226/RTL8221X
RTL8226 is the first version for realtek that compatible 2.5Gbps single PHY.
Since RTL8226 is single port only, realtek changes its name to RTL8221B from
the second
On Tue, Sep 29, 2020 at 11:23:03PM +0200, Daniel Borkmann wrote:
[ ... ]
> ---
> include/linux/skbuff.h | 5 +
> include/uapi/linux/bpf.h | 14 ++
> net/core/filter.c | 273 +++--
> tools/include/uapi/linux/bpf.h | 14 ++
> 4 files chang
> On Sep 29, 2020, at 8:23 PM, Alexei Starovoitov
> wrote:
>
> On Tue, Sep 29, 2020 at 5:20 PM Song Liu wrote:
>>
>> In preempt kernel, BPF_PROG_TEST_RUN on raw_tp triggers:
>>
>> [ 35.874974] BUG: using smp_processor_id() in preemptible []
>> code: new_name/87
>> [ 35.893983]
On Tue, Sep 29, 2020 at 12:58:49PM -0700, David Miller wrote:
> From: Petko Manolov
> Date: Tue, 29 Sep 2020 07:59:11 +0300
>
> > On 20-09-28 16:00:58, David Miller wrote:
> >> From: Petko Manolov Date: Sun, 27 Sep 2020
> >> 15:49:07 +0300
> >>
> >> > Re-sending these, now CC-ing the folks at
On Tue, Sep 29, 2020 at 10:25:30PM +0200, Thomas Gleixner wrote:
> From: Sebastian Andrzej Siewior
>
> kaweth_control() is almost the same as usb_control_msg() except for the
> memory allocation mode (GFP_ATOMIC vs GFP_NOIO) and the in_interrupt()
> check.
>
> All the invocations of kaweth_contr
On Wed, Sep 30, 2020 at 12:26 AM kernel test robot wrote:
>
> Hi Xin,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on net-next/master]
>
> url:
> https://github.com/0day-ci/linux/commits/Xin-Long/sctp-Implement-RFC6951-UDP-Enc
It's done.
On Wed, Sep 30, 2020 at 1:08 PM Julian Anastasov wrote:
>
>
> Hello,
>
> On Mon, 28 Sep 2020, longguang.yue wrote:
>
> > Outputting client,virtual,dst addresses info when tcp state changes,
> > which makes the connection debug more clear
> >
> > Signed-off-by: longguang.yue
> I stopped here.
>
> Thanks
Thanks for your comments Leon, I will resubmit after the changes
Thanks
Srini
Analysis of the structure receive_queue using pahole gives the
following stats.
/* size: 1280, cachelines: 20, members: 11 */
/* sum members: 1220, holes: 1, sum holes: 60 */
/* paddings: 2, sum paddings: 44 */
/* forced alignments: 2, forced holes: 1, sum forced hol
The structures virtnet_info and receive_queue have byte holes in
middle, and their members could do with some rearranging
(order-of-declaration wise) in order to overcome this.
Rearranging the members helps in:
* elimination the byte holes in the middle of the structures
* reduce the size of
Analysis of the structure virtnet_info using pahole gives the
following stats.
/* size: 256, cachelines: 4, members: 25 */
/* sum members: 245, holes: 3, sum holes: 11 */
/* paddings: 1, sum paddings: 4 */
Reordering the order in which the members of virtnet_info are declar
On Mon, Sep 28, 2020 at 03:49:49PM +0530, Srinivasan Raju wrote:
> This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC
> and LiFi-XL USB devices, which provide lightweight, highspeed secure and
> fully networked wireless communications via light.
>
> This driver implementation has been bas
Hello,
On Mon, 28 Sep 2020, longguang.yue wrote:
> Outputting client,virtual,dst addresses info when tcp state changes,
> which makes the connection debug more clear
>
> Signed-off-by: longguang.yue
OK, v5 can be used instead of fixing v4.
Acked-by: Julian Anastasov
> ---
Hi David,
The following pull-request contains BPF updates for your *net* tree.
We've added 7 non-merge commits during the last 14 day(s) which contain
a total of 7 files changed, 28 insertions(+), 8 deletions(-).
The main changes are:
1) fix xdp loading regression in libbpf for old kernels, fro
On 9/29/20 3:17 AM, Michal Kubecek wrote:
Hello,
our builds of s390x for zfcpdump fail since 5.9-rc1 with
BTFIDS vmlinux
FAILED unresolved symbol tcp_timewait_sock
make[1]: ***
[/home/abuild/rpmbuild/BUILD/kernel-zfcpdump-5.9.rc7/linux-5.9-rc7/Makefile:1176:
vmlinux] Error 255
The XFRMA_SET_MARK_MASK attribute can be set in states (4.19+)
It is optional and the kernel default is 0x
It is the mask of XFRMA_SET_MARK(a.k.a. XFRMA_OUTPUT_MARK in 4.18)
e.g.
./ip/ip xfrm state add output-mark 0x6 mask 0xab proto esp \
auth digest_null 0 enc cipher_null ''
ip xfrm sta
On Tue, Sep 29, 2020 at 4:50 PM Hao Luo wrote:
>
> v3 -> v4:
> - Rebasing
> - Cast bpf_[per|this]_cpu_ptr's parameter to void __percpu * before
>passing into per_cpu_ptr.
Looks good, but doesn't work:
./test_progs -t ksyms_btf
test_ksyms_btf:PASS:kallsyms_fopen 0 nsec
test_ksyms_btf:PASS:ks
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
tools/lib/bpf/btf.c
between commit:
1245008122d7 ("libbpf: Fix native endian assumption when parsing BTF")
from the bpf tree and commit:
3289959b97ca ("libbpf: Support BTF loading and raw data output in both
endia
On 29/09/20 2:17 pm, Petko Manolov wrote:
> On 20-09-29 13:50:28, Anant Thazhemadam wrote:
>> When get_registers() fails (which happens when usb_control_msg() fails)
>> in set_ethernet_addr(), the uninitialized value of node_id gets copied
>> as the address.
>>
>> Checking for the return values a
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/phy/realtek.c
between commit:
bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
from the net tree and commit:
66e22932eb79 ("net: phy: realtek: enable ALDPS to save power for RTL8211F"
On Tue, Sep 29, 2020 at 5:20 PM Song Liu wrote:
>
> In preempt kernel, BPF_PROG_TEST_RUN on raw_tp triggers:
>
> [ 35.874974] BUG: using smp_processor_id() in preemptible []
> code: new_name/87
> [ 35.893983] caller is bpf_prog_test_run_raw_tp+0xd4/0x1b0
> [ 35.900124] CPU: 1 PID: 87
On Tue, Sep 29, 2020 at 05:44:48PM -0700, Andrii Nakryiko wrote:
> On Tue, Sep 29, 2020 at 5:03 PM Alexei Starovoitov
> wrote:
> >
> > On Tue, Sep 29, 2020 at 04:28:39PM -0700, Andrii Nakryiko wrote:
> > > Add btf_dump__dump_type_raw() API that emits human-readable low-level BTF
> > > type
> > >
--
Hello
In addition to a major health crisis, the coronavirus outbreak is a
major economic disruption that causes people to lose their jobs and
make it more difficult to provide for their families. We've heard that
a little financial support can go a long way.
I'm Sheryll Goedert from
On Tue, Sep 29, 2020 at 04:03:45PM -0700, Andrii Nakryiko wrote:
> > bpf_map__set_pin_path()
> > bpf_create_map_in_map()<- create inner or outer map
> > bpf_map__reuse_fd(map, inner/outer_fd)
> > bpf_object__load(obj)
> > - bpf_object__load_xattr()
> > - bpf_object__create_maps()
> >
Julian, Pablo, Simon, Hi, ping
On Tue, Sep 29, 2020 at 10:15 AM yue longguang wrote:
>
> I sincerely apologize for the trouble which takes up much of your
> time. If the last patch does not work , would you please fix it?
> thanks
>
> On Mon, Sep 28, 2020 at 10:51 AM longguang.yue wrote:
> >
>
On Tue, Sep 29, 2020 at 3:25 PM Michael S. Tsirkin wrote:
>
> On Tue, Sep 29, 2020 at 03:17:50PM +0800, Tonghao Zhang wrote:
> > On Tue, Sep 29, 2020 at 2:22 PM Michael S. Tsirkin wrote:
> > >
> > > On Tue, Sep 29, 2020 at 02:10:56PM +0800, Tonghao Zhang wrote:
> > > > On Tue, Sep 29, 2020 at 1:5
On Tue, Sep 29, 2020 at 11:23:02PM +0200, Daniel Borkmann wrote:
> With its use in BPF, the cookie generator can be called very frequently
> in particular when used out of cgroup v2 hooks (e.g. connect / sendmsg)
> and attached to the root cgroup, for example, when used in v1/v2 mixed
> environment
From: Tonghao Zhang
Allow user configuring RXCSUM separately with ethtool -K,
reusing the existing virtnet_set_guest_offloads helper
that configures RXCSUM for XDP. This is conditional on
VIRTIO_NET_F_CTRL_GUEST_OFFLOADS.
If Rx checksum is disabled, LRO should also be disabled.
Cc: Michael S. T
After commit a8c7687bf216 ("caif_virtio: Check that vringh_config is not
null"), the variable err is being initialized with '-EINVAL' that is
meaningless. So remove it.
Signed-off-by: Jing Xiangfeng
---
drivers/net/caif/caif_virtio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
Tony, if you want me to actually apply this series, it must be submitted
properly with a proper "Subject: [PATCH net 0/2] ..." header posting explaing
at a high level what the patch series does, how it does it, and why it does
it that way.
It's ipvs's duty to do traffic statistic if packets get hit,
no matter what mode it is.
Signed-off-by: longguang.yue
---
net/netfilter/ipvs/ip_vs_conn.c | 14 --
net/netfilter/ipvs/ip_vs_core.c | 5 -
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/
From: Vladimir Oltean
Date: Wed, 30 Sep 2020 01:27:20 +0300
> The patches from RFC series "Offload tc-flower to mscc_ocelot switch
> using VCAP chains" have been split into 2:
> https://patchwork.ozlabs.org/project/netdev/list/?series=204810&state=*
>
> This is the boring part, that deals with t
On Tue, Sep 29, 2020 at 11:23:01PM +0200, Daniel Borkmann wrote:
> Similarly to 5a52ae4e32a6 ("bpf: Allow to retrieve cgroup v1 classid
> from v2 hooks"), add a helper to retrieve cgroup v1 classid solely
> based on the skb->sk, so it can be used as key as part of BPF map
> lookups out of tc from h
From: Shannon Nelson
Date: Tue, 29 Sep 2020 15:19:54 -0700
> Our link watchdog displayed a couple of unfriendly behaviors in some recent
> stress testing. These patches change the startup and stop timing in order
> to be sure that expected structures are ready to be used by the watchdog.
This d
From: Mat Martineau
Date: Tue, 29 Sep 2020 15:08:18 -0700
> The main fix is contained in patch 2, and that commit message explains
> the issue with not properly converting truncated DATA_FIN sequence
> numbers sent by the peer.
>
> With patch 2 adding an unlocked read of msk->ack_seq, patch 1 cl
From: Mat Martineau
Date: Tue, 29 Sep 2020 15:08:20 -0700
> The peer may send a DATA_FIN mapping with either a 32-bit or 64-bit
> sequence number. When a 32-bit sequence number is received for the
> DATA_FIN, it must be expanded to 64 bits before comparing it to the
> last acked sequence number.
From: Lorenzo Bianconi
Date: Tue, 29 Sep 2020 23:58:57 +0200
> Do not use rx_desc pointers if possible since rx descriptors are stored in
> uncached memory and dereferencing rx_desc pointers generate extra loads.
> This patch improves XDP_DROP performance of ~ 110Kpps (700Kpps vs 590Kpps)
> on Ma
Hi David,
Thank you for the quick application of the fixes.
Regards,
Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com
> Sent: Tuesday, September 29, 2020 at 2:24 PM
> From: "David Miller"
> To: kevinbr...@gmx.com
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH net v2
Fix follow warnings:
[net/core/pktgen.c:925]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'signed int'.
[net/core/pktgen.c:942]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'signed int'.
[net/core/
Fix follow warnings:
[net/core/net-sysfs.c:1161]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'int'.
[net/core/net-sysfs.c:1162]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'int'.
Reported-by: Hu
Ye Bin (2):
pktgen: Fix inconsistent of format with argument type in pktgen.c
net-sysfs: Fix inconsistent of format with argument type in
net-sysfs.c
net/core/net-sysfs.c | 4 ++--
net/core/pktgen.c| 10 +-
2 files changed, 7 insertions(+), 7 deletions(-)
--
2.25.4
On Tue, Sep 29, 2020 at 5:03 PM Alexei Starovoitov
wrote:
>
> On Tue, Sep 29, 2020 at 04:28:39PM -0700, Andrii Nakryiko wrote:
> > Add btf_dump__dump_type_raw() API that emits human-readable low-level BTF
> > type
> > information, same as bpftool output. bpftool is not switched to this API
> > be
On Tue, 29 Sep 2020 17:17:45 -0700 Shannon Nelson wrote:
> On 9/29/20 5:15 PM, Jakub Kicinski wrote:
> > On Tue, 29 Sep 2020 15:19:56 -0700 Shannon Nelson wrote:
> >> In one corner case scenario, the driver device lif setup can
> >> get delayed such that the ionic_watchdog_cb() timer goes off
> >
In preempt kernel, BPF_PROG_TEST_RUN on raw_tp triggers:
[ 35.874974] BUG: using smp_processor_id() in preemptible []
code: new_name/87
[ 35.893983] caller is bpf_prog_test_run_raw_tp+0xd4/0x1b0
[ 35.900124] CPU: 1 PID: 87 Comm: new_name Not tainted 5.9.0-rc6-g615bd02bf #1
[ 35.907
The ice driver can, optionally, load other package files for different
packet processing pipeline configurations. Add the "comms" package as
another option.
Signed-off-by: Tony Nguyen
---
LICENSE.ice_enhanced | 38 +
WHENCE
On 9/29/20 5:15 PM, Jakub Kicinski wrote:
On Tue, 29 Sep 2020 15:19:56 -0700 Shannon Nelson wrote:
In one corner case scenario, the driver device lif setup can
get delayed such that the ionic_watchdog_cb() timer goes off
before the ionic->lif is set, thus causing a NULL pointer panic.
We catch t
On Tue, Sep 29, 2020 at 05:09:48PM -0700, Jakub Kicinski wrote:
> On Tue, 29 Sep 2020 20:47:23 +0200 Andrew Lunn wrote:
> > > Do you mean report supported range via extack?
> >
> > Yes.
> >
> > 811ac400ea33 ("net: phy: dp83869: Add speed optimization feature")
> >
> > was merged recently. It h
From: Jacob Keller
If the driver initializes in safe mode, it will call
ice_set_safe_mode_caps. This results in clearing the capabilities
structures, in order to set them up for operating in safe mode, ensuring
many features are disabled.
This has a side effect of also clearing the capability bi
From: Jacob Keller
The ice driver needs to wait for a firmware response to each command to
write a block of data to the scratch area used to update the device
firmware. The driver currently waits for up to 1 second for this to be
returned.
It turns out that firmware might take longer than 1 seco
On Tue, 29 Sep 2020 15:19:56 -0700 Shannon Nelson wrote:
> In one corner case scenario, the driver device lif setup can
> get delayed such that the ionic_watchdog_cb() timer goes off
> before the ionic->lif is set, thus causing a NULL pointer panic.
> We catch the problem by checking for a NULL lif
On Tue, 29 Sep 2020 15:19:55 -0700 Shannon Nelson wrote:
> We need to be better at making sure we don't have a link check
> watchdog go off while we're shutting things down, so let's stop
> the timer as soon as we start the remove.
>
> Meanwhile, since that was the only thing in
> ionic_dev_teardo
On Tue, 29 Sep 2020 20:47:23 +0200 Andrew Lunn wrote:
> > Do you mean report supported range via extack?
>
> Yes.
>
> 811ac400ea33 ("net: phy: dp83869: Add speed optimization feature")
>
> was merged recently. It has:
>
> + default:
> + phydev_err(phydev,
> +
On Tue, Sep 29, 2020 at 03:06:04PM -0700, Andrii Nakryiko wrote:
> Libbpf compiles .o's for static and shared library modes separately, so no
> need to specify -fPIC for both. Keep it only for shared library mode.
Acked-by: Martin KaFai Lau
On Tue, Sep 29, 2020 at 03:06:03PM -0700, Andrii Nakryiko wrote:
> For some reason compiler doesn't complain about uninitialized variable, fixed
> in previous patch, if libbpf is compiled without -O2 optimization level. So do
> compile it with -O2 and never let similar issue slip by again. -Wall is
On Tue, Sep 29, 2020 at 04:28:39PM -0700, Andrii Nakryiko wrote:
> Add btf_dump__dump_type_raw() API that emits human-readable low-level BTF type
> information, same as bpftool output. bpftool is not switched to this API
> because bpftool still needs to perform all the same BTF type processing logi
On Tue, Sep 29, 2020 at 03:06:02PM -0700, Andrii Nakryiko wrote:
> Fix obvious unitialized variable use that wasn't reported by compiler. libbpf
> Makefile changes to catch such errors are added separately.
Acked-by: Martin KaFai Lau
On Tue, Sep 29, 2020 at 03:50:13PM -0700, Song Liu wrote:
> In preempt kernel, BPF_PROG_TEST_RUN on raw_tp triggers:
>
> [ 35.874974] BUG: using smp_processor_id() in preemptible []
> code: new_name/87
> [ 35.893983] caller is bpf_prog_test_run_raw_tp+0xd4/0x1b0
> [ 35.900124] CPU: 1
On Tue, 29 Sep 2020, Paul Moore wrote:
> As pointed out by Herbert in a recent related patch, the LSM hooks
> should pass the address family in addition to the xfrm flow as the
> family information is needed to safely access the flow.
>
> While this is not technically a problem for the current LS
This series implements the iproute2 side of the new
DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK.
This attribute is used to allow userspace to indicate what a device should
do with various subsections of a flash component when updating. For example,
a flash component might contain vital data such as t
Add support for specifying the overwrite sections to allow in the flash
update command. This is done by adding a new "overwrite" option which
can take either "settings" or "identifiers" passing the overwrite mode
multiple times will combine the fields using bitwise-OR.
Signed-off-by: Jacob Keller
The recent changes to support an overwrite mask require the _BITUL macro
to be included. The uapi/linux/devlink.h header did not include
resulting in compile failures using the macros that relied
upon it.
Signed-off-by: Jacob Keller
---
include/uapi/linux/devlink.h | 2 ++
1 file changed, 2 ins
Add btf_dump__dump_type_raw() API that emits human-readable low-level BTF type
information, same as bpftool output. bpftool is not switched to this API
because bpftool still needs to perform all the same BTF type processing logic
to do JSON output, so benefits are pretty much zero.
Raw BTF type ou
Extend btf_dump APIs with ability to dump raw textual representation of BTF
types, with the same format as used by `bpftool btf dump file` command. Such
functionality is really useful for debugging issues with BTF, testing, BTF
introspection, etc. It is going to be used in BPF selftests for validat
Add test validating that btf_dump works fine with BTFs that are modified and
incrementally generated.
Signed-off-by: Andrii Nakryiko
---
.../selftests/bpf/prog_tests/btf_dump.c | 105 ++
1 file changed, 105 insertions(+)
diff --git a/tools/testing/selftests/bpf/prog_tests/
Ensure that btf_dump can accommodate new BTF types being appended to BTF
instance after struct btf_dump was created. This came up during attemp to
use btf_dump for raw type dumping in selftests, but given changes are not
excessive, it's good to not have any gotchas in API usage, so I decided to
sup
Cross-validate raw BTF dump and writable BTF in a single selftest. Raw type
dump checks also serve as a good self-documentation.
Signed-off-by: Andrii Nakryiko
---
.../selftests/bpf/prog_tests/btf_write.c | 67 ++-
1 file changed, 64 insertions(+), 3 deletions(-)
diff --git
On 9/29/20 1:25 PM, Thomas Gleixner wrote:
From: Sebastian Andrzej Siewior
The in_interrupt() usage in this driver tries to figure out which context
may sleep and which context may not sleep. in_interrupt() is not really
suitable as it misses both preemption disabled and interrupt disabled
invo
On Tue, Sep 29, 2020 at 2:42 AM Hangbin Liu wrote:
>
> On Mon, Sep 28, 2020 at 08:30:42PM -0700, Andrii Nakryiko wrote:
> > > @@ -431,6 +431,7 @@ bpf_map__prev(const struct bpf_map *map, const struct
> > > bpf_object *obj);
> > > /* get/set map FD */
> > > LIBBPF_API int bpf_map__fd(const struc
In preempt kernel, BPF_PROG_TEST_RUN on raw_tp triggers:
[ 35.874974] BUG: using smp_processor_id() in preemptible []
code: new_name/87
[ 35.893983] caller is bpf_prog_test_run_raw_tp+0xd4/0x1b0
[ 35.900124] CPU: 1 PID: 87 Comm: new_name Not tainted 5.9.0-rc6-g615bd02bf #1
[ 35.907
On 9/29/20 2:56 PM, Jacob Keller wrote:
For some devices, updating the flash can take significant time during
operations where no status can meaningfully be reported. This can be
somewhat confusing to a user who sees devlink appear to hang on the
terminal waiting for the device to update.
Recent
On 9/29/2020 2:54 PM, Paul Moore wrote:
> As pointed out by Herbert in a recent related patch, the LSM hooks
> should pass the address family in addition to the xfrm flow as the
> family information is needed to safely access the flow.
>
> While this is not technically a problem for the current LSM
There are some targets (register blocks) in the Ocelot switch that are
instantiated more than once. For example, the VCAP IS1, IS2 and ES0
blocks all share the same register layout for interacting with the cache
for the TCAM and the action RAM.
For the VCAPs, the procedure for servicing them is ac
Now that we are deriving these from the constants exposed by the
hardware, we can delete the static info we're keeping in the driver.
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/felix_vsc9959.c | 12
drivers/net/dsa/ocelot/seville_vsc9953.c | 13 -
dr
The 'cnt' variable is actually used for 2 purposes, to hold the number
of sub-words per VCAP entry, and the number of sub-words per VCAP
action.
In fact, I'm pretty sure these 2 numbers can never be different from one
another. By hardware definition, the entry (key) TCAM rows are divided
into the
And rename the existing find to ocelot_vcap_block_find_filter_by_index.
The index is the position in the TCAM, and the id is the flow cookie
given by tc.
Signed-off-by: Vladimir Oltean
---
Changes since RFC v2:
None.
Changes since RFC v1:
None.
drivers/net/ethernet/mscc/ocelot_vcap.c | 26
From: Xiaoliang Yang
When calculating the offsets for the current entry within the row and
placing them inside struct vcap_data, the function assumes half key
entry (2 keys per row).
This patch modifies the vcap_data_offset_get() function to calculate a
correct data offset when the setting VCAP
When we'll make the switch to multiple chain offloading, we'll want to
know first what VCAP block the rule is offloaded to. This impacts what
keys are available. Since the VCAP block is determined by what actions
are used, parse the action first.
Signed-off-by: Vladimir Oltean
---
drivers/net/et
Currently a new filter is created, containing just enough correct
information to be able to call ocelot_vcap_block_find_filter_by_index()
on it.
This will be limiting us in the future, when we'll have more metadata
associated with a filter, which will matter in the stats() and destroy()
callbacks,
This gets rid of one of the 2 variables named, very generically,
"count".
Signed-off-by: Vladimir Oltean
---
Changes since RFC v2:
Patch is new.
drivers/net/ethernet/mscc/ocelot_vcap.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mscc
In the Ocelot switches there are 3 TCAMs: VCAP ES0, IS1 and IS2, which
have the same configuration interface, but different sets of keys and
actions. The driver currently only supports VCAP IS2.
In preparation of VCAP IS1 and ES0 support, the existing code must be
generalized to work with any VCAP
As a preparation step for the offloading to IS1, let's create the
infrastructure for talking with this hardware block.
Signed-off-by: Vladimir Oltean
---
Changes since RFC v2:
Shuffled patch order.
Changes since RFC v1:
Added definitions for VSC9953 and VSC7514.
arch/mips/boot/dts/mscc/ocelot.
The numbers in struct vcap_props are not intuitive to derive, because
they are not a straightforward copy-and-paste from the reference manual
but instead rely on a fairly detailed level of understanding of the
layout of an entry in the TCAM and in the action RAM. For this reason,
bugs are very easy
The patches from RFC series "Offload tc-flower to mscc_ocelot switch
using VCAP chains" have been split into 2:
https://patchwork.ozlabs.org/project/netdev/list/?series=204810&state=*
This is the boring part, that deals with the prerequisites, and not with
tc-flower integration. Apart from the ini
As a preparation step for the offloading to ES0, let's create the
infrastructure for talking with this hardware block.
Signed-off-by: Vladimir Oltean
---
arch/mips/boot/dts/mscc/ocelot.dtsi| 3 +-
drivers/net/dsa/ocelot/felix_vsc9959.c | 50 ++
drivers/net/dsa/oc
From: Xiaoliang Yang
Although it doesn't look like it is possible to hit these conditions
from user space, there are 2 separate, but related, issues.
First, the ocelot_vcap_block_get_filter_index function, née
ocelot_ace_rule_get_index_id prior to the aae4e500e106 ("net: mscc:
ocelot: generalize
Our link watchdog displayed a couple of unfriendly behaviors in some recent
stress testing. These patches change the startup and stop timing in order
to be sure that expected structures are ready to be used by the watchdog.
Shannon Nelson (2):
ionic: stop watchdog timer earlier on remove
ioni
In one corner case scenario, the driver device lif setup can
get delayed such that the ionic_watchdog_cb() timer goes off
before the ionic->lif is set, thus causing a NULL pointer panic.
We catch the problem by checking for a NULL lif just a little
earlier in the callback.
Signed-off-by: Shannon N
We need to be better at making sure we don't have a link check
watchdog go off while we're shutting things down, so let's stop
the timer as soon as we start the remove.
Meanwhile, since that was the only thing in
ionic_dev_teardown(), simplify and remove that function.
Signed-off-by: Shannon Nels
Libbpf compiles .o's for static and shared library modes separately, so no
need to specify -fPIC for both. Keep it only for shared library mode.
Signed-off-by: Andrii Nakryiko
---
tools/lib/bpf/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/lib/bpf/Makefile
For some reason compiler doesn't complain about uninitialized variable, fixed
in previous patch, if libbpf is compiled without -O2 optimization level. So do
compile it with -O2 and never let similar issue slip by again. -Wall is added
unconditionally, so no need to specify it again.
Signed-off-by:
Fix obvious unitialized variable use that wasn't reported by compiler. libbpf
Makefile changes to catch such errors are added separately.
Fixes: 3289959b97ca ("libbpf: Support BTF loading and raw data output in both
endianness")
Signed-off-by: Andrii Nakryiko
---
tools/lib/bpf/btf.c | 2 +-
1 f
The peer may send a DATA_FIN mapping with either a 32-bit or 64-bit
sequence number. When a 32-bit sequence number is received for the
DATA_FIN, it must be expanded to 64 bits before comparing it to the
last acked sequence number. This expansion was missing.
Closes: https://github.com/multipath-tc
The msk->ack_seq value is sometimes read without the msk lock held, so
make proper use of READ_ONCE and WRITE_ONCE.
Signed-off-by: Mat Martineau
---
net/mptcp/options.c | 4 ++--
net/mptcp/protocol.c | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/mptcp/options.
The main fix is contained in patch 2, and that commit message explains
the issue with not properly converting truncated DATA_FIN sequence
numbers sent by the peer.
With patch 2 adding an unlocked read of msk->ack_seq, patch 1 cleans up
access to that data with READ_ONCE/WRITE_ONCE.
This does i
On 9/29/2020 10:25 PM, Thomas Gleixner wrote:
From: Sebastian Andrzej Siewior
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be seperated or the context be conveyed in an argument passed by th
On 9/29/2020 10:25 PM, Thomas Gleixner wrote:
bcrmgf_netif_rx() uses in_interrupt to chose between netif_rx() and
netif_rx_ni(). in_interrupt() usage in drivers is phased out.
Convey the execution mode via an 'inirq' argument through the various
callchains leading to brcmf_netif_rx():
brcmf_pci
Do not use rx_desc pointers if possible since rx descriptors are stored in
uncached memory and dereferencing rx_desc pointers generate extra loads.
This patch improves XDP_DROP performance of ~ 110Kpps (700Kpps vs 590Kpps)
on Marvell Espressobin
Analyzed-by: Ilias Apalodimas
Signed-off-by: Lorenz
For some devices, updating the flash can take significant time during
operations where no status can meaningfully be reported. This can be
somewhat confusing to a user who sees devlink appear to hang on the
terminal waiting for the device to update.
Recent changes to the kernel interface allow suc
1 - 100 of 458 matches
Mail list logo
