[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9A5A96DE-791A-4667-8B8B-F1ED3BDC2FB7@intel.com>
Date: Wed, 2 Sep 2015 16:53:33 +0000
From: "Rustad, Mark D" <mark.d.rustad@...el.com>
To: Tom Herbert <tom@...bertland.com>
CC: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
"nhorman@...hat.com" <nhorman@...hat.com>,
"sassmann@...hat.com" <sassmann@...hat.com>,
"jogreene@...hat.com" <jogreene@...hat.com>
Subject: Re: [net-next 06/19] ixgbe: Add support for VXLAN RX offloads
> On Sep 1, 2015, at 8:31 PM, Tom Herbert <tom@...bertland.com> wrote:
>
>> @@ -7240,6 +7267,10 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
>> struct ipv6hdr *ipv6;
>> } hdr;
>> struct tcphdr *th;
>> + struct sk_buff *skb;
>> +#ifdef CONFIG_IXGBE_VXLAN
>> + u8 encap = false;
>> +#endif /* CONFIG_IXGBE_VXLAN */
>> __be16 vlan_id;
>>
>> /* if ring doesn't have a interrupt vector, cannot perform ATR */
>> @@ -7253,16 +7284,36 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
>
> Isn't this a function in the transmit path? What do these changes have
> to do with RX offloads?
Yes, it is in the transmit path. ATR sets up rules for delivering received packets to the correct queue. So this is setting things up for the receive side to work better. New hardware capabilities now make it possible to do this for VXLAN traffic.
--
Mark Rustad, Networking Division, Intel Corporation
Download attachment "signature.asc" of type "application/pgp-signature" (842 bytes)
Powered by blists - more mailing lists