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
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, 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
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
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
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
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
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
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
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
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
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
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
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
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 switch which pads non-zero octets, this
causes kernel hardware
21 matches
Mail list logo
