Hello, Saeed
On Tue, Dec 4, 2018 at 10:27 PM Saeed Mahameed wrote:
> static int mlx5e_handle_pflag(struct net_device *netdev,
> u32 wanted_flags,
> - enum mlx5e_priv_flag flag,
> - mlx5e_pflag_handler
Hello, Saeed
On Tue, Dec 4, 2018 at 10:26 PM Saeed Mahameed wrote:
> +static int mlx5e_get_rss_hash_opt(struct mlx5e_priv *priv,
> + struct ethtool_rxnfc *nfc)
...
> + tt = flow_type_to_traffic_type(nfc->flow_type);
> +
> + if (tt ==
On Tue, Dec 4, 2018 at 10:26 PM Saeed Mahameed wrote:
> +static const struct mlx5e_tirc_config
> +tirc_default_config[MLX5E_NUM_INDIR_TIRS] = {
Is it okay to define an array in a header??? No link error???
I must be dumb...
On Tue, Dec 4, 2018 at 10:27 PM Saeed Mahameed wrote:
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> b/drivers/net/ethernet/mellanox/mlx5/core/en.h
> index a429553002a6..49e90ac5dc8b 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
> +++
On Sun, Dec 2, 2018 at 4:37 AM Tariq Toukan wrote:
>
> From: Saeed Mahameed
>
> MLX4_EN depends on NETDEVICES, ETHERNET and INET Kconfigs.
> Make sure they are listed in MLX4_EN Kconfig dependencies.
>
> This fixes the following build break:
>
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18:
On Tue, Dec 4, 2018 at 9:06 AM Eric Dumazet wrote:
>
>
>
> On 12/04/2018 08:59 AM, David Laight wrote:
> > Where does 68 come from?
>
> Min IPv4 MTU per RFC791
>
What's wrong with using IPV4_MIN_MTU instead of 68
even in just comment?
On Tue, Dec 4, 2018 at 6:05 PM Saeed Mahameed wrote:
>
> After the following flow counters API refactoring:
> ("net/mlx5: Use flow counter IDs and not the wrapping cache object")
> flow counters private data structures mlx5_fc_cache and mlx5_fc are
> redundantly exposed in fs_core.h, they have
On Tue, Dec 4, 2018 at 6:06 PM Saeed Mahameed wrote:
>
> +static inline u8 get_cqe_opcode(struct mlx5_cqe64 *cqe)
Make it const please.
On Tue, Nov 27, 2018 at 10:10 PM Cong Wang wrote:
>
> When an ethernet frame is padded to meet the minimum ethernet frame
> size, the padding octets are not covered by the hardware checksum.
> Fortunately the padding octets are ususally zero's, which don't affect
> checksum. H
On Tue, Dec 4, 2018 at 4:59 PM Saeed Mahameed wrote:
>
> Cong, you are missing some important details, hardware can only parse a
> handful of protocols IP/TCP/UDP some tunneling like vxlan,GRE, etc..
> but for complicated protocols and new generic tunneling protocols,
> which the hardware wasn't
On Tue, Dec 4, 2018 at 5:06 PM Saeed Mahameed wrote:
>
> Hi Cong, sorry to hear that, i will take your patch evaluate and test
> personally, will do the needed changes and post it later.
Please don't. I am withdrawing my SoB too. To avoid any legal
issues, please speak to a legal expert before
On Tue, Dec 4, 2018 at 5:16 PM Saeed Mahameed wrote:
> Please understand that RX data path is really sensitive and we are
> trying to find the optimal fix of any issue here, sorry for any
> inconvenience.
I am sorry for sending out this patch, I am certain that it wastes
a lot of your time.
The
On Tue, Dec 4, 2018 at 1:16 PM Eric Dumazet wrote:
>
> Erm I never suggested to get rid of CHECKSUM_COMPLETE...
> My suggestion was to reorder the mlx5 logic to match mlx4 one.
>
> CHECKSUM_COMPLETE is very nice _when_/_if_ the NIC is unable to
> fully dissect a packet and validate L4, as a
On Tue, Dec 4, 2018 at 11:21 AM Saeed Mahameed
wrote:
> we are still working on it.
No, I give up.
Sorry for wasting time. Let's save everyone's time by discarding it!! :)
On Mon, Dec 3, 2018 at 10:14 PM Cong Wang wrote:
>
> When an ethernet frame is padded to meet the minimum ethernet frame
> size, the padding octets are not covered by the hardware checksum.
> Fortunately the padding octets are ususally zero's, which don't affect
> checksum. H
On Tue, Dec 4, 2018 at 11:17 AM Saeed Mahameed
wrote:
>
> On Mon, Dec 3, 2018 at 11:52 PM Eric Dumazet wrote:
> >
> > On Mon, Dec 3, 2018 at 11:30 PM Cong Wang wrote:
> > >
> > > On Mon, Dec 3, 2018 at 11:08 PM Eric Dumazet wrote:
> > > >
> &g
On Mon, Dec 3, 2018 at 11:51 PM Eric Dumazet wrote:
> > If it really validates L3/L4 checksum, then a full-packet checksum
> > is not needed.
>
> Yes, this is exactly what CHECKSUM_UNNECESSARY means.
> linux stack does not have to perform the check another time.
So you are suggesting to get rid
On Sat, Dec 1, 2018 at 12:38 PM Cong Wang wrote:
>
> is_last_ethertype_ip() is used to check IP/IPv6 protocol before
> parsing IP/IPv6 headers.
>
> But __vlan_get_protocol() is only bound to skb->len, a malicious
> packet could exhaust all skb->len by inserting sufficien
On Tue, Dec 4, 2018 at 11:33 AM Saeed Mahameed
wrote:
>
> On Sat, Dec 1, 2018 at 12:38 PM Cong Wang wrote:
> >
> > is_last_ethertype_ip() is used to check IP/IPv6 protocol before
> > parsing IP/IPv6 headers.
> >
> > But __vlan_get_protocol() is only bound
On Tue, Dec 4, 2018 at 11:28 AM Saeed Mahameed
wrote:
>
> We are against having inline keywords in c file, so better if you
> move this function to a header file an force the inline keyword there.
Two points:
1. The existing code without my patch has inline keyword. Why
not move it from the
On Mon, Dec 3, 2018 at 11:08 PM Eric Dumazet wrote:
>
> The hardware has probably validated the L3 & L4 checksum just fine.
>
> Note that if ip_summed is CHECKSUM_UNNECESSARY, the padding bytes (if any)
> have no impact on the csum that has been verified by the NIC.
Why? Why does the hardware
On Mon, Dec 3, 2018 at 10:34 PM Eric Dumazet wrote:
>
> On Mon, Dec 3, 2018 at 10:14 PM Cong Wang wrote:
> >
> > When an ethernet frame is padded to meet the minimum ethernet frame
> > size, the padding octets are not covered by the hardware checksum.
> >
CHECKSUM_COMPLETE are
friends"),
Cc: Saeed Mahameed
Cc: Eric Dumazet
Cc: Tariq Toukan
Signed-off-by: Cong Wang
---
.../net/ethernet/mellanox/mlx5/core/en_rx.c | 22 ++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core
On Mon, Dec 3, 2018 at 3:17 PM David Miller wrote:
>
> Saeed, are you going to take care of this?
David, I will send v3 to switch to CHECKSUM_NONE for these short
frames, which also could avoid parsing IP headers.
Thanks.
On Sat, Dec 1, 2018 at 12:38 PM Cong Wang wrote:
>
> is_last_ethertype_ip() is used to check IP/IPv6 protocol before
> parsing IP/IPv6 headers.
One thing I noticed while reviewing the assembly code is that
is_last_ethertype_ip() is no longer inlined after this patch.
I think I sh
On Sun, Dec 2, 2018 at 9:11 PM Cong Wang wrote:
>
> On Sun, Dec 2, 2018 at 12:56 AM Tariq Toukan wrote:
> >
> > > + } else if (*proto == htons(ETH_P_IPV6)) {
> >
> > No need for an else here, the first if block always returns.
>
>
> Yea
On Sun, Dec 2, 2018 at 12:56 AM Tariq Toukan wrote:
>
>
>
> On 01/12/2018 10:38 PM, Cong Wang wrote:
> > + if (*proto == htons(ETH_P_IP)) {
> > + if (unlikely(*network_depth > skb->len - sizeof(struct
> > iphdr)))
> > +
so we
have to check if we are still safe to continue to parse IP/IPv6 header.
If not, treat it as non-IP packet.
This should not cause any crash as we stil have tail room in skb,
but we can't just rely on it either.
Cc: Tariq Toukan
Cc: Saeed Mahameed
Signed-off-by: Cong Wang
---
drivers/net/et
On Thu, Nov 29, 2018 at 1:46 PM Eric Dumazet wrote:
>
>
>
> On 11/29/2018 01:13 PM, Duyck, Alexander H wrote:
>
> > Instead of just checking for the max it might make more sense to do a
> > check using skb_is_gso, and then if true use gso_segs, otherwise just
> > default to 1.
> >
> > Also your
d5d625 ("net/sched: act_police: disallow 'goto chain' on
> fallback control action")
> Reported-by: Dan Carpenter
> Signed-off-by: Davide Caratti
Acked-by: Cong Wang
On Wed, Nov 28, 2018 at 7:50 PM Eric Dumazet wrote:
>
> On Wed, Nov 28, 2018 at 7:40 PM Cong Wang wrote:
> >
> > On Wed, Nov 28, 2018 at 4:07 PM Eric Dumazet wrote:
> > >
> > > A NIC is supposed to deliver frames, even the ones that 'seem' bad.
> >
&
On Wed, Nov 28, 2018 at 4:07 PM Eric Dumazet wrote:
>
> A NIC is supposed to deliver frames, even the ones that 'seem' bad.
A quick test shows this is not the case for mlx5.
With the trafgen script you gave to me, with tot_len==40, the dest host
could receive all the packets. Changing tot_len
On Wed, Nov 28, 2018 at 3:57 PM Cong Wang wrote:
> But again, I kinda feel the hardware already does the sanity check,
> otherwise we have much more serious trouble in mlx5e_lro_update_hdr()
> which parses into TCP header.
>
While we are on this page, mlx5e_lro_update_hdr() incorre
On Wed, Nov 28, 2018 at 3:50 PM Eric Dumazet wrote:
>
> On Wed, Nov 28, 2018 at 2:16 PM Cong Wang wrote:
> >
> > On Wed, Nov 28, 2018 at 7:00 AM Eric Dumazet wrote:
> > >
> > > Nice packet of death alert.
> > >
> > > pad_len can be 0xF
ed
Signed-off-by: Cong Wang
---
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 9b6bd2b51556..f7c5dbb0ffcd 100644
---
On Wed, Nov 28, 2018 at 7:00 AM Eric Dumazet wrote:
>
> Nice packet of death alert.
>
> pad_len can be 0xFF67 here, if frame_len is smaller than pad_offset.
Unless IP header is malformed, how could it be?
Speaking of IP header sanity, I am totally aware of it, I don't check it because
I
aeed Mahameed
Cc: Eric Dumazet
Signed-off-by: Cong Wang
---
.../net/ethernet/mellanox/mlx5/core/en_rx.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 16985ca324
On Tue, Nov 27, 2018 at 5:49 PM Eric Dumazet wrote:
>
>
> Sure this patch handles short frames, but I am saying the issue is
> more generic than that.
Yeah. Let's fix one problem in one patch.
I will clarify that I am only fixing short frames in v2, as I need to update
it anyway.
Thanks!
On Tue, Nov 27, 2018 at 5:25 PM Eric Dumazet wrote:
>
>
>
> On 11/27/2018 04:07 PM, Cong Wang wrote:
> > On Tue, Nov 27, 2018 at 3:48 PM Eric Dumazet wrote:
>
> >>
> >> But the padding might be added on normal packets (say 1000 bytes + 3 bytes
>
On Tue, Nov 27, 2018 at 5:11 PM Saeed Mahameed wrote:
>
> On Tue, 2018-11-27 at 16:07 -0800, Cong Wang wrote:
> > On Tue, Nov 27, 2018 at 3:48 PM Eric Dumazet
> > wrote:
> > > The bug here is that mlx5 csum only includes the data in IP frame.
> > >
>
On Tue, Nov 27, 2018 at 3:48 PM Eric Dumazet wrote:
>
>
>
> On 11/27/2018 03:21 PM, Cong Wang wrote:
> > When an ethernet frame is padded to meet the minimum ethernet frame
> > size, the padding octets are not covered by the hardware checksum.
> > Fortunately t
On Tue, Nov 27, 2018 at 3:21 PM Cong Wang wrote:
> + if (proto == htons(ETH_P_IP)) {
> + struct iphdr *ipv4 = ip_p;
> +
> + pad_offset = network_depth + be16_to_cpu(ipv4->tot_len);
> + } else if (proto == htons(ETH_P_IPV6)) {
> +
aeed Mahameed
Cc: Eric Dumazet
Signed-off-by: Cong Wang
---
.../net/ethernet/mellanox/mlx5/core/en_rx.c | 36 +++
1 file changed, 36 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 16985ca324
Cc: Herbert Xu
Signed-off-by: Cong Wang
---
net/core/dev.c| 1 +
net/core/skbuff.c | 18 +-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 368dc3b49dc0..ee0a4ac0bbb6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
On Wed, Nov 21, 2018 at 11:33 AM Saeed Mahameed wrote:
>
> On Wed, 2018-11-21 at 10:26 -0800, Eric Dumazet wrote:
> > On Wed, Nov 21, 2018 at 10:17 AM Cong Wang
> > wrote:
> > > On Wed, Nov 21, 2018 at 5:05 AM Eric Dumazet <
> > > eric.duma...@gmail.com&g
On Wed, Nov 21, 2018 at 10:26 AM Eric Dumazet wrote:
>
> On Wed, Nov 21, 2018 at 10:17 AM Cong Wang wrote:
> >
> > On Wed, Nov 21, 2018 at 5:05 AM Eric Dumazet wrote:
> > >
> > >
> > >
> > > On 11/20/2018 06:13 PM, Cong Wang wrote:
>
On Wed, Nov 21, 2018 at 5:05 AM Eric Dumazet wrote:
>
>
>
> On 11/20/2018 06:13 PM, Cong Wang wrote:
> > Currently, we only dump a few selected skb fields in
> > netdev_rx_csum_fault(). It is not suffient for debugging checksum
> > fault. This patch introduces
On Tue, Nov 20, 2018 at 1:19 PM Davide Caratti wrote:
> @@ -257,25 +261,28 @@ static int tcf_police_act(struct sk_buff *skb, const
> struct tc_action *a,
> }
>
> now = ktime_get_ns();
> - toks = min_t(s64, now - p->tcfp_t_c, p->tcfp_burst);
> +
me a 'police'
> action is newly created, to avoid the following lockdep splat:
Acked-by: Cong Wang
On Tue, Nov 20, 2018 at 3:30 PM Eric Dumazet wrote:
>
> On Tue, Nov 20, 2018 at 3:28 PM David Miller wrote:
> >
> > Applied.
>
> We need a fix to make lockdep happy, as reported by Cong.
>
> Cong, do you want to handle this ?
>
I hope Davide could send a followup fix and really test it
with
off-by: Cong Wang
---
include/linux/skbuff.h | 5 +
net/core/dev.c | 6 +-
net/core/skbuff.c | 49 ++
3 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index afddb5c17
Signed-off-by: Cong Wang
---
include/linux/skbuff.h | 5 +
net/core/skbuff.c | 2 ++
2 files changed, 7 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a2e8297a5b00..afddb5c17ce5 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
On Tue, Nov 20, 2018 at 1:19 PM Davide Caratti wrote:
>
> after 'police' configuration parameters were converted to use RCU instead
> of spinlock, the state variables used to compute the traffic rate (namely
> 'tcfp_toks', 'tcfp_ptoks' and 'tcfp_t_c') are erroneously read/updated in
> the traffic
On Fri, Nov 16, 2018 at 12:15 PM Cong Wang wrote:
>
> On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet wrote:
> >
> > You could use trafgen to cook such a frame and confirm the theory.
> >
> > Something like :
>
> I will try it.
I just tried it, it doesn't ma
On Sun, Nov 18, 2018 at 8:02 PM Herbert Xu wrote:
>
> On Fri, Nov 16, 2018 at 01:32:50PM -0800, Cong Wang wrote:
> >
> > This is true only when there is a skb_checksum_init*() or
> > skb_checksum_validate*() prior to it, it seems not true for
> > nf_ip_checksum() wh
On Fri, Nov 16, 2018 at 12:06 PM Cong Wang wrote:
>
> Hmm, now I see how it works. Actually it uses the differences between
> these two check's as the difference between hardware checksum with
> skb_checksum().
>
Well...
This is true only when there is a sk
On Thu, Nov 15, 2018 at 8:52 PM Eric Dumazet wrote:
>
> It is very possible NIC provides an incorrect CHECKSUM_COMPLETE, in the
> case non zero trailer bytes were added by a buggy switch (or host)
>
> Saeed can comment/confirm, but the theory is that the NIC does header
> analysis and
> computes
On Thu, Nov 15, 2018 at 8:59 PM Herbert Xu wrote:
>
> On Thu, Nov 15, 2018 at 08:52:23PM -0800, Eric Dumazet wrote:
> >
> > It is very possible NIC provides an incorrect CHECKSUM_COMPLETE, in the
> > case non zero trailer bytes were added by a buggy switch (or host)
>
> We should probably change
On Thu, Nov 15, 2018 at 8:50 PM Herbert Xu wrote:
>
> On Thu, Nov 15, 2018 at 06:23:38PM -0800, Cong Wang wrote:
> >
> > > Normally if the hardware's partial checksum is valid then we just
> > > trust it and send the packet along. However, if the partial
> >
On Thu, Nov 15, 2018 at 5:52 PM Herbert Xu wrote:
>
> On Thu, Nov 15, 2018 at 03:16:02PM -0800, Cong Wang wrote:
> > The following evidences indicate this check is likely wrong:
> >
> > 1. In the assignment "skb->csum_valid = !sum", sum==0 indic
rbert
Cc: Eric Dumazet
Signed-off-by: Cong Wang
---
net/core/datagram.c | 4 ++--
net/core/dev.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/datagram.c b/net/core/datagram.c
index 57f3a6fcfc1e..e542a9a212a7 100644
--- a/net/core/datagram.c
+++ b/net/core/data
prove too,
they imply tcf_idr_check_alloc() returns either 0 or 1.
Of course, this can be done with a separated patch.
>
> Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action")
> Signed-off-by: Davide Caratti
I think your patch is correct.
Acked-by: Cong Wang
On Tue, Nov 13, 2018 at 10:01 AM Willem de Bruijn
wrote:
>
> On Mon, Nov 12, 2018 at 2:49 PM Cong Wang wrote:
> >
> > Currently netdev_rx_csum_fault() only shows a device name,
> > we need more information about the skb for debugging csum
> > failures.
> >
Signed-off-by: Cong Wang
---
include/linux/skbuff.h | 1 -
net/core/skbuff.c | 13 -
2 files changed, 14 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 7dcfb5591dc3..9f5bd97a26bd 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
__tcp_checksum_complete() is 100% same with __skb_checksum_complete()
and there is no other caller except tcp_checksum_complete().
So, just use __skb_checksum_complete() there.
Signed-off-by: Cong Wang
---
include/net/tcp.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
csum_complete_sw=0 csum_valid=0 csum_level=0
Note, I use pr_err() just to be consistent with the existing one.
Signed-off-by: Cong Wang
---
include/linux/netdevice.h | 5 +++--
net/core/datagram.c | 2 +-
net/core/dev.c| 11 +--
net/core/skbuff.c | 4 ++--
net/sunrpc
On Fri, Nov 9, 2018 at 8:16 PM David Miller wrote:
>
> Didn't you move this function into net/core/skbuff.c? :-)
At the time when I created this patch, that patch didn't hit net-next yet. :)
>
> Please respin.
Sure. I will send v2, as I need to cleanup the mixed commas and
spaces too.
Thanks.
(Cc Randy)
On Fri, Nov 9, 2018 at 10:13 AM yupeng wrote:
>
> The snmp_counter.rst run a set of simple experiments, explains the
> meaning of snmp counters depend on the experiments' results. This is
> an initial version, only covers a small part of the snmp counters.
I don't look into much
On Fri, Nov 9, 2018 at 6:02 PM Yunsheng Lin wrote:
>
> On 2018/11/10 9:42, Cong Wang wrote:
> > On Fri, Nov 9, 2018 at 5:39 PM Yunsheng Lin wrote:
> >>
> >> On 2018/11/10 3:43, Cong Wang wrote:
> >>> Currently netdev_rx_csum_fault() only shows a device
On Fri, Nov 9, 2018 at 5:39 PM Yunsheng Lin wrote:
>
> On 2018/11/10 3:43, Cong Wang wrote:
> > Currently netdev_rx_csum_fault() only shows a device name,
> > we need more information about the skb for debugging.
> >
> > Sample output:
> >
> >
-by: Cong Wang
---
include/linux/netdevice.h | 5 +++--
net/core/datagram.c | 6 +++---
net/core/dev.c| 10 --
net/sunrpc/socklib.c | 2 +-
4 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index
RXFCS").
Fixes: ca4ef4574f1e ("ip: fix IP_CHECKSUM handling")
Cc: Paolo Abeni
Cc: Eric Dumazet
Cc: Willem de Bruijn
Signed-off-by: Cong Wang
---
net/ipv4/ip_sockglue.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip
On Thu, Nov 8, 2018 at 2:17 PM Eric Dumazet wrote:
>
> On Thu, Nov 8, 2018 at 2:04 PM Cong Wang wrote:
> >
> > When subtracting the checksum of a block of data,
> > csum_block_sub() must be used to respect the offset.
> >
> > We learned this lesson from bot
__skb_checksum_complete_head() and __skb_checksum_complete()
are both declared in skbuff.h, they fit better in skbuff.c
than datagram.c.
Cc: Stefano Brivio
Signed-off-by: Cong Wang
---
net/core/datagram.c | 43 ---
net/core/skbuff.c | 43
On Thu, Nov 8, 2018 at 12:14 PM Stefano Brivio wrote:
>
> On Thu, 8 Nov 2018 12:02:00 -0800
> Cong Wang wrote:
>
> > On Thu, Nov 8, 2018 at 11:54 AM Stefano Brivio wrote:
> > >
> > > Hi,
> > >
> > > On Thu, 8 Nov 2018 11:49:49 -080
On Thu, Nov 8, 2018 at 11:54 AM Stefano Brivio wrote:
>
> Hi,
>
> On Thu, 8 Nov 2018 11:49:49 -0800
> Cong Wang wrote:
>
> > +EXPORT_SYMBOL(__skb_checksum_complete);
> > +
> > /* Both of above in one bottle. */
>
> Maybe you should also update/d
__skb_checksum_complete_head() and __skb_checksum_complete()
are both declared in skbuff.h, they fit better in skbuff.c
than datagram.c.
Signed-off-by: Cong Wang
---
net/core/datagram.c | 43 ---
net/core/skbuff.c | 43
On Thu, Nov 1, 2018 at 3:59 PM Paweł Staszewski wrote:
>
>
>
> W dniu 31.10.2018 o 22:17, Cong Wang pisze:
> > On Wed, Oct 31, 2018 at 2:05 PM Saeed Mahameed wrote:
> >> Cong, How often does this happen ? can you some how verify if the
> >> problematic packe
On Thu, Nov 8, 2018 at 12:10 AM peng yu wrote:
>
> I'm planing to write a document which explains the meaning of the
> kernel snmp counters, and combine the explanations with some tests,
> because I found lots of the 'TcpExt' and 'IpExt' counters are not
> explained in any document. Here is a
t;net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends")
Cc: Eric Dumazet
Signed-off-by: Cong Wang
---
net/ipv4/ip_fragment.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 9b0158fa431f..d6ee343fd
On Wed, Oct 31, 2018 at 2:05 PM Saeed Mahameed wrote:
>
> Cong, How often does this happen ? can you some how verify if the
> problematic packet has extra end padding after the ip payload ?
For us, we need 10+ hours to get one warning. This is also
why we never capture the packet that causes
On Tue, Oct 30, 2018 at 11:42 AM Eric Dumazet wrote:
>
> On Tue, Oct 30, 2018 at 11:09 AM Cong Wang wrote:
>
> > At least skb_header_pointer() is marked as __must_check, I don't see
> > you check its return value here.
>
> This can not fail here.
>
> skb->len
On Mon, Oct 29, 2018 at 8:08 PM Eric Dumazet wrote:
>
>
>
> On 10/29/2018 07:41 PM, Cong Wang wrote:
> > On Mon, Oct 29, 2018 at 7:25 PM Eric Dumazet wrote:
> >>
> >>
> >>
> >> On 10/29/2018 07:21 PM, Cong Wang wrote:
> >&
On Tue, Oct 30, 2018 at 12:57 AM Eric Dumazet wrote:
> -static __be32 mlx5e_get_fcs(struct sk_buff *skb)
> +static u32 mlx5e_get_fcs(const struct sk_buff *skb)
> {
> - int last_frag_sz, bytes_in_prev, nr_frags;
> - u8 *fcs_p1, *fcs_p2;
> - skb_frag_t *last_frag;
> -
On Tue, Oct 30, 2018 at 10:50 AM Eric Dumazet wrote:
>
>
>
> On 10/30/2018 10:32 AM, Cong Wang wrote:
>
> > Unlike Pawel's case, we don't use vlan at all, maybe this is why we see
> > it much less frequently than Pawel.
> >
> > Also, it is probably not speci
On Tue, Oct 30, 2018 at 7:16 AM Eric Dumazet wrote:
>
>
>
> On 10/30/2018 01:09 AM, Paweł Staszewski wrote:
> >
> >
> > W dniu 30.10.2018 o 08:29, Eric Dumazet pisze:
> >>
> >> On 10/29/2018 11:09 PM, Dimitris Michailidis wrote:
> >>
> >>> Indeed this is a bug. I would expect it to produce
(Cc'ing Eric)
On Sat, Oct 27, 2018 at 12:47 PM Nikola Ciprich
wrote:
>
> Hi,
>
> just wanted to report, thet after switching to 4.19 (fro 4.14.x, so maybe
> the problem appeared somewhere between), I'm getting tons of similar
> messages:
>
> Oct 27 09:06:27 xxx kernel: br501: hw csum failure
>
(Adding Eric and Dimitris into Cc)
On Mon, Oct 29, 2018 at 7:27 PM Cong Wang wrote:
>
> Hi,
>
> On Mon, Oct 29, 2018 at 5:19 PM Paweł Staszewski
> wrote:
> >
> > Sorry not complete - followed by hw csum:
> >
> > [ 342.190831] vlan1490: hw csum failure
On Mon, Oct 29, 2018 at 7:25 PM Eric Dumazet wrote:
>
>
>
> On 10/29/2018 07:21 PM, Cong Wang wrote:
> > On Mon, Oct 29, 2018 at 7:14 PM Eric Dumazet wrote:
> >>
> >> Would not it be simpler to set ip_summed to CHECKSUM_NONE (no need to save
> >&g
Hi,
On Mon, Oct 29, 2018 at 5:19 PM Paweł Staszewski wrote:
>
> Sorry not complete - followed by hw csum:
>
> [ 342.190831] vlan1490: hw csum failure
> [ 342.190835] CPU: 52 PID: 0 Comm: swapper/52 Not tainted 4.19.0+ #1
> [ 342.190836] Call Trace:
> [ 342.190839]
> [ 342.190849]
On Mon, Oct 29, 2018 at 7:14 PM Eric Dumazet wrote:
>
> Would not it be simpler to set ip_summed to CHECKSUM_NONE (no need to save
> old_csum) ?
For !CHECKSUM_COMPLETE, ip_summed should be untouched, right?
If you mean only setting to CHECKSUM_NONE for CHECKSUM_COMPLETE case,
the end result
rcsum() and CHECKSUM_COMPLETE are friends")
Cc: Eric Dumazet
Signed-off-by: Cong Wang
---
net/core/skbuff.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 946de0e24c87..5decd6e6d2b6 100644
--- a/net/core/skbuff.c
+++ b/net/cor
On Fri, Oct 26, 2018 at 4:35 AM Marco Berizzi wrote:
> Apologies for bothering you again.
> I applied your patch to 4.19, but after issuing this
> command:
>
> root@Calimero:~# tc qdisc add dev eth0 root handle 1:0 hfsc default 1
> root@Calimero:~# ping 10.81.104.1
> PING 10.81.104.1
since TC core doesn't initialize the
> chain handle.
>
> Signed-off-by: Davide Caratti
Acked-by: Cong Wang
ze the
> chain handle.
>
> Signed-off-by: Davide Caratti
Acked-by: Cong Wang
On Thu, Oct 18, 2018 at 8:30 AM Davide Caratti wrote:
> The alternative is, we systematically forbid usage of 'goto chain' in
> tcfg_paction, so that:
>
> # tc f a dev v0 egress matchall action random determ goto chain 4 5
>
> is systematically rejected with -EINVAL. This comand never worked, so
On Mon, Oct 15, 2018 at 4:36 AM Eran Ben Elisha wrote:
> Hi,
>
> This suggested fix introduced a regression while using netconsole module
> with mlx5_core module loaded.
It is already reported here:
https://marc.info/?l=linux-kernel=153917359528669=2
>
> During irq handling, we hit a warning
On Wed, Oct 17, 2018 at 9:42 PM David Miller wrote:
>
> From: Amritha Nambiar
> Date: Fri, 12 Oct 2018 06:53:30 -0700
>
> > Added support in tc flower for filtering based on port ranges.
> > This is a rework of the RFC patch at:
> > https://patchwork.ozlabs.org/patch/969595/
>
> You never
On Tue, Oct 16, 2018 at 10:38 AM Davide Caratti wrote:
>
> On Mon, 2018-10-15 at 11:31 -0700, Cong Wang wrote:
> > On Sat, Oct 13, 2018 at 8:23 AM Davide Caratti wrote:
> > >
> > > On Fri, 2018-10-12 at 13:57 -0700, Cong Wang wrote:
> > > > Why not
On Sat, Oct 13, 2018 at 8:23 AM Davide Caratti wrote:
>
> On Fri, 2018-10-12 at 13:57 -0700, Cong Wang wrote:
> > Why not just validate the fallback action in each action init()?
> > For example, checking tcfg_paction in tcf_gact_init().
> >
> > I don't see
1 - 100 of 1974 matches
Mail list logo
