On Tue, Oct 27, 2015, at 23:03, Tom Herbert wrote:
> On Tue, Oct 27, 2015 at 2:42 PM, Hannes Frederic Sowa
> <han...@stressinduktion.org> wrote:
> > I posted v3 just now. I would like to let David consider it for net
> > inclusion. We can work on how to lift this limitation then in net-next,
> > okay? I am currently in favor of a new netdev-feature. What do you
> > think? Your RFC series could help here, too.
> >
> I really do not like the feature flag, it's just a bandaid over the
> real problem-- in fact my goal is to eliminate NETIF_F_IP{V6}_CSUM and
> just have NETIF_F_HW_CSUM. I will repost the helper patches, but we
> really do need to start fixing this stuff in the drivers instead of
> more hacking in the stack.It would be great if this is doable but I doubt so. There might be a lot of unresponsive driver maintainers and I don't see that we should simply eliminate IPv4 csum offloading for those drivers, too. Sometimes it is hard to patch drivers without documentation. I am against lifting restrictions which will have unforeseeable consequences for some people (as in partial communication errors) or having huge performance drawbacks (as in disabling ipv4 csum offloading, too). I could even imagine this needs to be more configurable as in how many extension headers some hardware can process, I fear. One extension header might be okay (jumping over a fragmentation header), but two... I simply don't know, yet. Maybe there is no problem with hardware at all. I don't really see this series as a hack. ;) Unluckily it seems we don't get feedback from the hardware about not being able to construct a proper checksum, so we cannot even close the loop and add code which warns us about misbehaving drivers. Bye, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
