NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/53562: bridge(4) breaks segmentation / TX checksum offloading

The following reply was made to PR kern/53562; it has been noted by GNATS.

From: Masanobu SAITOH <>
To: Christoph Badura <>,
Cc:, Rin Okuyama <>,
 Ryota Ozaki <>
Subject: Re: kern/53562: bridge(4) breaks segmentation / TX checksum
Date: Sat, 6 Apr 2019 14:24:20 +0900

 On 2019/04/03 7:58, Christoph Badura wrote:
 > There is one more problem:
 > We use the same bits in csum_flags to indicate both that the hardware
 > *needs to do* offloading and that the hardware *has done* offloading.
 > IIRC, this wasn't a problem when this interface was introduced, because we
 > didn't have bridge(4) yet and packets would either travel down the stack
 > from kernel to harware or up the stack from hardware to kernel only.
 > Adding bridge(4) changed that, hence the problems.
 > To finaly resolve that for good we need separate flags to indicate that
 > the hardware did offloading and what the status of that is.
 In current implementation, csum_flags field is cleared when a packet
 is forwarded to an outgoing (interface). The IPv{4,6} forwarding path
 and bridge do so. (If a filter function does policy routing, it's also
 be required.) If there is a unknown path which doesn't clear csum_flags,
 it should be fixed.
  Do you know any real use case which get this problem?
 To separate flags into input and output, it solves the problem,
 but I don't know it's the good solution or not.
 It does not directly related to the separating, I think the correct
 way is to clear flags when those are evaluated. When a packet is
 a tunneling (encapsulated) packet, the flags should be cleared when
 the outer header is checked and passed to the next input to not to
 misunderstand the input flags.
 > --chris
                 SAITOH Masanobu (

Home | Main Index | Thread Index | Old Index