netdev - Re: [RFC][net-next-2.6 PATCH 3/4] ethtool: set hard_header_len using ETH_FLAG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikJpsFC=ZsTWtxwSp-aQRDoZ9fy1p-ZxR+v8jVm@mail.gmail.com>
Date:	Mon, 25 Oct 2010 15:45:01 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	John Fastabend <john.r.fastabend@...el.com>, netdev@...r.kernel.org
Subject: Re: [RFC][net-next-2.6 PATCH 3/4] ethtool: set hard_header_len using ETH_FLAG_{TX|RX}VLAN

On Fri, Oct 22, 2010 at 6:00 AM, Ben Hutchings
<bhutchings@...arflare.com> wrote:
> On Thu, 2010-10-21 at 15:10 -0700, John Fastabend wrote:
>> Toggling the vlan tx|rx hw offloads needs to set the hard_header_len
>> as well otherwise we end up using LL_RESERVED_SPACE incorrectly.
>> This results in pskb_expand_head() being used unnecessarily.
>>
>> This add a check in ethtool_op_set_flags to catch the ETH_FLAG_TXVLAN
>> flag and set the header length.
> [...]
>
> Note that not every driver that implements the set_flags operation calls
> back to ethtool_op_set_flags().

Currently all of the drivers that support toggling this using ethtool
call into ethtool_op_set_flags.  Even if they don't, things will
continue to work correctly, albeit with a performance hit, so it's not
a catastrophe.

This does assume that drivers which support offloading will start with
it enabled.  If they don't and just use the non-vlan header length
then this will drop the header length down even further when
offloading is enabled.  All current drivers that support toggling do
start with offloading enabled, so maybe it's not that big a deal.

Another issue is that cards that don't support vlan offloading at all
probably won't take the header into account, so they'll get hit every
time.

When we are using vlan devices we also manually add the vlan header
length but it doesn't update if we change the underlying device.  It
seems a little redundant to have to do it in both places.

I like that this is generic and independent of vlan devices.
Hopefully we can figure out these corner cases (or maybe decide that
they're not important or this is strictly an improvement).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html