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, 2018-12-04 at 12:35 -0800, Cong Wang wrote:
> 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 <
> > > xiyou.wangc...@gmail.com> wrote:
> > > > On Mon, Dec 3, 2018 at 11:08
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 12/04/2018 12:35 PM, Cong Wang wrote:
> 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:
>
> The
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. However, we have a
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:
> > > >
> > > > The hardware has probably validated the L3 & L4
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 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:
> > >
> > > The hardware has probably validated the L3 & L4 checksum just fine.
> > >
> > > Note that if ip_summed is
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. However, we have a
On Mon, Dec 3, 2018 at 11:30 PM Cong Wang wrote:
>
> 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
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
Resent to netdev@ without htm formatting, sorry.
On Mon, Dec 3, 2018 at 11:08 PM Eric Dumazet wrote:
>
>
>
> On Mon, Dec 3, 2018 at 10:48 PM Cong Wang wrote:
>>
>> 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
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.
> > Fortunately the padding octets are
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. 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
15 matches
Mail list logo
