From: Saeed Mahameed
> Sent: 19 January 2019 00:46
> On Thu, Jan 17, 2019 at 5:19 PM Christoph Paasch
> wrote:
> >
> > Hello,
> >
> > On Sun, Jan 6, 2019 at 3:12 AM Saeed Mahameed
> > wrote:
> > >
> > > On Sat, Jan 5, 2019 at 8:35 PM Nikola Ciprich
> > > wrote:
> > > >
> > > > Hi Saeed,
> > > >
On Thu, Jan 17, 2019 at 5:19 PM Christoph Paasch
wrote:
>
> Hello,
>
> On Sun, Jan 6, 2019 at 3:12 AM Saeed Mahameed
> wrote:
> >
> > On Sat, Jan 5, 2019 at 8:35 PM Nikola Ciprich
> > wrote:
> > >
> > > Hi Saeed,
> > >
> > >
> > > > Most likely the same issue, we are finalizing the patch initia
Hello,
On Sun, Jan 6, 2019 at 3:12 AM Saeed Mahameed wrote:
>
> On Sat, Jan 5, 2019 at 8:35 PM Nikola Ciprich
> wrote:
> >
> > Hi Saeed,
> >
> >
> > > Most likely the same issue, we are finalizing the patch initially
> > > proposed by Cong, you can find it here, I plan to submit it next week,
>
On Sat, Jan 5, 2019 at 8:35 PM Nikola Ciprich
wrote:
>
> Hi Saeed,
>
>
> > Most likely the same issue, we are finalizing the patch initially
> > proposed by Cong, you can find it here, I plan to submit it next week,
> > after all the regression tests.
> >
> > https://git.kernel.org/pub/scm/linux/k
Hi Saeed,
> Most likely the same issue, we are finalizing the patch initially
> proposed by Cong, you can find it here, I plan to submit it next week,
> after all the regression tests.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git/commit/?h=topic/csum-fix
>
> It would be n
> Hi Nikola
>
> 4.19 is missing this priv flag, it was only submitted to 4.20
>
> commit b856df28f9230a47669efbdd57896084caadb2b3
> Author: Or Gerlitz
> Date: Sun Jul 1 08:58:38 2018 +
>
> net/mlx5e: Allow reporting of checksum unnecessary
>
>
> > I'm using following cards:
> >
> >
On Thu, 2018-12-13 at 09:40 +0100, Nikola Ciprich wrote:
> Hi Saeed,
>
> > for now i feel that you don't want csum complete in your servers
> > and we
> > already have the tool for that, just do:
> >
> > ethtool --set-priv-flags rx_no_csum_complete on
> > ethtool --show-priv-flags
> > Private f
Hi Saeed,
> for now i feel that you don't want csum complete in your servers and we
> already have the tool for that, just do:
>
> ethtool --set-priv-flags rx_no_csum_complete on
> ethtool --show-priv-flags
> Private flags for p5p1:
> rx_cqe_moder : on
> tx_cqe_moder : off
> rx_cqe_
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. However, we have a swi
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 yo
On Tue, 2018-12-04 at 12:50 -0800, Cong Wang wrote:
> 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!!
> :)
Hi Cong, sorry to hear that, i will take your patch eva
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 3:17 PM David Miller wrote:
>
> From: Cong Wang
> Date: Tue, 27 Nov 2018 22:10:13 -0800
>
> > 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 us
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.
From: Cong Wang
Date: Tue, 27 Nov 2018 22:10:13 -0800
> 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. However, we have a
On Wed, Nov 28, 2018 at 8:09 PM Eric Dumazet wrote:
>
> On Wed, Nov 28, 2018 at 7:53 PM Cong Wang wrote:
> >
> > 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
On Wed, Nov 28, 2018 at 4:05 PM Cong Wang wrote:
>
> 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 w
On Wed, Nov 28, 2018 at 7:53 PM Cong Wang wrote:
>
> 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 th
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.
> >
> > A quick test shows this is not the case for
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.
>
> A quick test shows this is not the case for mlx5.
>
> With the trafgen script you gave to me, with tot_len==40,
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 to
On 11/28/2018 04:05 PM, Cong Wang wrote:
> While we are on this page, mlx5e_lro_update_hdr() incorrectly assumes
> TCP header is located right after struct iphdr, which is wrong if we could
> have IP options on this path.
>
> It could the hardware which already verified this corner case though
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.
>
LRO is a different beast.
For packets that are not recognized as LRO ca
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() incorrectly assumes
TC
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 0xFF67 here, if frame_len is smaller than pad_offset.
> >
>
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 0xFF67 here, if frame_len is smaller than pad_offset.
>
> Unless IP header is malformed, how could it be?
This is totally somet
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 kno
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. However, we have a swi
28 matches
Mail list logo
