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
20 matches
Mail list logo
