On Mon, 2015-10-05 at 09:23 -0700, Tom Herbert wrote:
>
> 1) Drivers may advertise NETIF_F_HW_CSUM. The stack will indicate
> checksum offload exclusively using the
> CHECKSUM_PARTIAL/csum_start/csum_offset interface. No additional
> interfaces (bits in skbuff should not be needed)
> 2) A driver m
> On Oct 5, 2015, at 9:23 AM, Tom Herbert wrote:
>
> 4) To help drivers for devices with limited offload capabilities we'll
> define a helper function to check for typical restrictions (.e.g. IPv4
> only, TCP/UDP only. no encapsulation, no IPv6 extension headers,
> etc.). I am working on this hel
On Mon, Oct 5, 2015 at 4:16 AM, David Woodhouse wrote:
> On Tue, 2015-09-29 at 15:52 -0700, Tom Herbert wrote:
>> Please look at ixgbe_tx_csum in ixgbe driver. This one example of how
>> a driver can determine whether the checksum being offloaded is TCP or
>> UDP. The bug in this driver is...
>
>
On Tue, 2015-09-29 at 15:52 -0700, Tom Herbert wrote:
> Please look at ixgbe_tx_csum in ixgbe driver. This one example of how
> a driver can determine whether the checksum being offloaded is TCP or
> UDP. The bug in this driver is...
I think it serves better as an example of why we don't *want* dr
On Tue, Sep 29, 2015 at 12:12 AM, David Woodhouse wrote:
> On Mon, 2015-09-28 at 20:04 -0700, Tom Herbert wrote:
>>
>> > I've been pondering a bit of a redesign in this space. I think the
>> > skb struct should be explicit in its instructions to hardware for
>> > which offloads to do for each pac
On Mon, 2015-09-28 at 20:04 -0700, Tom Herbert wrote:
>
> > I've been pondering a bit of a redesign in this space. I think the
> > skb struct should be explicit in its instructions to hardware for
> > which offloads to do for each packet.
> >
> > In this way, the stack would be *directly* telling
On Mon, 2015-09-28 at 12:37 -0700, Tom Herbert wrote:
> I think it's easier to just call skb_checksum_help from the driver
> when the packet is actually sent to the device (should be no cost for
> late binding).
That's true for checksum. Not for things like TSO though, and I wonder
if it's worth k
On Mon, Sep 28, 2015 at 6:38 PM, Jesse Brandeburg
wrote:
> On Mon, Sep 28, 2015 at 12:37 PM, Tom Herbert wrote:
>> On Mon, Sep 28, 2015 at 12:26 PM, David Woodhouse
>> wrote:
>>> On Mon, 2015-09-28 at 12:13 -0700, Tom Herbert wrote:
> Perhaps a better solution would be a bit in the sk
On Mon, Sep 28, 2015 at 12:37 PM, Tom Herbert wrote:
> On Mon, Sep 28, 2015 at 12:26 PM, David Woodhouse wrote:
>> On Mon, 2015-09-28 at 12:13 -0700, Tom Herbert wrote:
>>>
>>> > Perhaps a better solution would be a bit in the skbuff which indicates
>>> > that it *is* a TCP or UDP checksum. That
On Mon, Sep 28, 2015 at 12:26 PM, David Woodhouse wrote:
> On Mon, 2015-09-28 at 12:13 -0700, Tom Herbert wrote:
>>
>> > Perhaps a better solution would be a bit in the skbuff which indicates
>> > that it *is* a TCP or UDP checksum. That would be set by our UDP and
>> > TCP sockets, cleared by enc
On Mon, 2015-09-28 at 12:13 -0700, Tom Herbert wrote:
>
> > Perhaps a better solution would be a bit in the skbuff which indicates
> > that it *is* a TCP or UDP checksum. That would be set by our UDP and
> > TCP sockets, cleared by encapsulation, also set if appropriate by
> > skb_partial_csum_set
>> Also, this doesn't help those drivers that that can offload TCP and
>> UDP for IPv6 but only if there are no extension headers, in those
>> case the driver needs to look at the packet to see if it is a
>> "simple" UDP/TCP packet.
>
> Hm, are such devices even permitted to set NETIF_F_IPV6_CSUM?
On Mon, 2015-09-28 at 10:03 -0700, Tom Herbert wrote:
> > + if features & NETIF_F_V4_CSUM) && protocol == htons(ETH_P_IP))
> > ||
> > +((features & NETIF_F_V6_CSUM) && protocol ==
> > htons(ETH_P_IPV6))) &&
> > + (sk_protocol == IPPROTO_TCP || sk_protocol == IPPRO
On Fri, Sep 25, 2015 at 5:55 AM, David Woodhouse wrote:
> The check in harmonize_features() is supposed to match the skb against
> the features of the device in question, and prevent us from handing a
> skb to a device which can't handle it.
>
> It doesn't work correctly. A device with NETIF_F_IP_
The check in harmonize_features() is supposed to match the skb against
the features of the device in question, and prevent us from handing a
skb to a device which can't handle it.
It doesn't work correctly. A device with NETIF_F_IP_CSUM or
NETIF_F_IPV6_CSUM capabilities is only required to checksu
15 matches
Mail list logo
