All of lore.kernel.org
 help / color / mirror / Atom feed
* Question on ixgbe flow director
@ 2017-03-07 23:43 ` tndave
  0 siblings, 0 replies; 10+ messages in thread
From: tndave @ 2017-03-07 23:43 UTC (permalink / raw)
  To: intel-wired-lan; +Cc: netdev, Sowmini Varadhan

Hi,

I have few questions regarding ixgbe flow director.
As per my understanding flow director in ixgbe can work in 2 exclusive ways,
a. Using ATR filters - where flow director is setup in HW by driver
identifying transmit traffic. And based on that, receive traffic of the
same flow get assigned/directed to same queue.

b. Perfect filter, where user can manually program flow director using
ethtool so that receive packets gets directed to specified rx queue
(depending on on how ethtool flow-type and action etc,.); But with
perfect filters there is no intelligence involved alike ATR has on
identifying transit, right?

Few question regarding ixgbe ATR,
1. does ATR works in case if protocol is UDP? (Based on the current
ixgbe_atr() it only supports TCP)
2. Does ATR flow director can be programmed using ethtool?
(As per my understanding only perfect filter can be programmed from
ethtool, is that so?)

Thanks in advance,
-Tushar

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Intel-wired-lan] Question on ixgbe flow director
@ 2017-03-07 23:43 ` tndave
  0 siblings, 0 replies; 10+ messages in thread
From: tndave @ 2017-03-07 23:43 UTC (permalink / raw)
  To: intel-wired-lan

Hi,

I have few questions regarding ixgbe flow director.
As per my understanding flow director in ixgbe can work in 2 exclusive ways,
a. Using ATR filters - where flow director is setup in HW by driver
identifying transmit traffic. And based on that, receive traffic of the
same flow get assigned/directed to same queue.

b. Perfect filter, where user can manually program flow director using
ethtool so that receive packets gets directed to specified rx queue
(depending on on how ethtool flow-type and action etc,.); But with
perfect filters there is no intelligence involved alike ATR has on
identifying transit, right?

Few question regarding ixgbe ATR,
1. does ATR works in case if protocol is UDP? (Based on the current
ixgbe_atr() it only supports TCP)
2. Does ATR flow director can be programmed using ethtool?
(As per my understanding only perfect filter can be programmed from
ethtool, is that so?)

Thanks in advance,
-Tushar


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Intel-wired-lan] Question on ixgbe flow director
  2017-03-07 23:43 ` [Intel-wired-lan] " tndave
@ 2017-03-08 15:39   ` Alexander Duyck
  -1 siblings, 0 replies; 10+ messages in thread
From: Alexander Duyck @ 2017-03-08 15:39 UTC (permalink / raw)
  To: tndave; +Cc: intel-wired-lan, netdev, Sowmini Varadhan

On Tue, Mar 7, 2017 at 3:43 PM, tndave <tushar.n.dave@oracle.com> wrote:
> Hi,
>
> I have few questions regarding ixgbe flow director.
> As per my understanding flow director in ixgbe can work in 2 exclusive ways,
> a. Using ATR filters - where flow director is setup in HW by driver
> identifying transmit traffic. And based on that, receive traffic of the
> same flow get assigned/directed to same queue.

So ATR for ixgbe uses the Flow Director signature filters.  Basically
the signature filters are purely hash based filters.  The easiest way
to think of it is it is essentially a beefed up version of RSS.

> b. Perfect filter, where user can manually program flow director using
> ethtool so that receive packets gets directed to specified rx queue
> (depending on on how ethtool flow-type and action etc,.); But with
> perfect filters there is no intelligence involved alike ATR has on
> identifying transit, right?

You are right.  The perfect match filters are the ones we configure
via ethtool.  You are correct in that ATR logic is not involved so
there is no matching up an Rx flow to a Tx flow.

> Few question regarding ixgbe ATR,
> 1. does ATR works in case if protocol is UDP? (Based on the current
> ixgbe_atr() it only supports TCP)

It could, but the software for doing ATR flow identification,
ixgbe_atr(), only works on TCP.  The reasoning behind it is that Flow
Director doesn't filter fragmented frames and UDP can be fragmented.

> 2. Does ATR flow director can be programmed using ethtool?
> (As per my understanding only perfect filter can be programmed from
> ethtool, is that so?)

You can enable/disable the ATR filters via the NTUPLE feaure flag.
Basically it toggles between ATR mode, and NTUPLE mode.  In NTUPLE
mode the perfect filters are enabled and can be configured via
ethtool.

> Thanks in advance,
> -Tushar

Hope that helps.

- Alex

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Intel-wired-lan] Question on ixgbe flow director
@ 2017-03-08 15:39   ` Alexander Duyck
  0 siblings, 0 replies; 10+ messages in thread
From: Alexander Duyck @ 2017-03-08 15:39 UTC (permalink / raw)
  To: intel-wired-lan

On Tue, Mar 7, 2017 at 3:43 PM, tndave <tushar.n.dave@oracle.com> wrote:
> Hi,
>
> I have few questions regarding ixgbe flow director.
> As per my understanding flow director in ixgbe can work in 2 exclusive ways,
> a. Using ATR filters - where flow director is setup in HW by driver
> identifying transmit traffic. And based on that, receive traffic of the
> same flow get assigned/directed to same queue.

So ATR for ixgbe uses the Flow Director signature filters.  Basically
the signature filters are purely hash based filters.  The easiest way
to think of it is it is essentially a beefed up version of RSS.

> b. Perfect filter, where user can manually program flow director using
> ethtool so that receive packets gets directed to specified rx queue
> (depending on on how ethtool flow-type and action etc,.); But with
> perfect filters there is no intelligence involved alike ATR has on
> identifying transit, right?

You are right.  The perfect match filters are the ones we configure
via ethtool.  You are correct in that ATR logic is not involved so
there is no matching up an Rx flow to a Tx flow.

> Few question regarding ixgbe ATR,
> 1. does ATR works in case if protocol is UDP? (Based on the current
> ixgbe_atr() it only supports TCP)

It could, but the software for doing ATR flow identification,
ixgbe_atr(), only works on TCP.  The reasoning behind it is that Flow
Director doesn't filter fragmented frames and UDP can be fragmented.

> 2. Does ATR flow director can be programmed using ethtool?
> (As per my understanding only perfect filter can be programmed from
> ethtool, is that so?)

You can enable/disable the ATR filters via the NTUPLE feaure flag.
Basically it toggles between ATR mode, and NTUPLE mode.  In NTUPLE
mode the perfect filters are enabled and can be configured via
ethtool.

> Thanks in advance,
> -Tushar

Hope that helps.

- Alex

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Intel-wired-lan] Question on ixgbe flow director
  2017-03-08 15:39   ` Alexander Duyck
@ 2017-03-08 19:30     ` tndave
  -1 siblings, 0 replies; 10+ messages in thread
From: tndave @ 2017-03-08 19:30 UTC (permalink / raw)
  To: Alexander Duyck; +Cc: intel-wired-lan, netdev, Sowmini Varadhan



On 03/08/2017 07:39 AM, Alexander Duyck wrote:
> On Tue, Mar 7, 2017 at 3:43 PM, tndave <tushar.n.dave@oracle.com>
> wrote:
>> Hi,
>>
>> I have few questions regarding ixgbe flow director. As per my
>> understanding flow director in ixgbe can work in 2 exclusive ways,
>>  a. Using ATR filters - where flow director is setup in HW by
>> driver identifying transmit traffic. And based on that, receive
>> traffic of the same flow get assigned/directed to same queue.
>
> So ATR for ixgbe uses the Flow Director signature filters. Basically
> the signature filters are purely hash based filters.  The easiest way
> to think of it is it is essentially a beefed up version of RSS.
Alex,

Thanks for the info.
>
>> b. Perfect filter, where user can manually program flow director
>> using ethtool so that receive packets gets directed to specified
>> rx queue (depending on on how ethtool flow-type and action etc,.);
>> But with perfect filters there is no intelligence involved alike
>> ATR has on identifying transit, right?
>
> You are right.  The perfect match filters are the ones we configure
> via ethtool.  You are correct in that ATR logic is not involved so
> there is no matching up an Rx flow to a Tx flow.
>
>> Few question regarding ixgbe ATR, 1. does ATR works in case if
>> protocol is UDP? (Based on the current ixgbe_atr() it only
>> supports TCP)
>
> It could, but the software for doing ATR flow identification,
> ixgbe_atr(), only works on TCP.  The reasoning behind it is that Flow
> Director doesn't filter fragmented frames and UDP can be fragmented.
So we could just add code in ixgbe_atr() for non-fragmented udp packets!
However question is if it is going to work w.r.t ATR? TCP is connected
stream vs udp is stateless and single udp socket can talk to multiple
endpoints.

>
>> 2. Does ATR flow director can be programmed using ethtool? (As per
>> my understanding only perfect filter can be programmed from
>> ethtool, is that so?)
>
> You can enable/disable the ATR filters via the NTUPLE feaure flag.
> Basically it toggles between ATR mode, and NTUPLE mode.  In NTUPLE
> mode the perfect filters are enabled and can be configured via
> ethtool.
Got it.

Thanks.

-Tushar
>
>> Thanks in advance, -Tushar
>
> Hope that helps.
>
> - Alex
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Intel-wired-lan] Question on ixgbe flow director
@ 2017-03-08 19:30     ` tndave
  0 siblings, 0 replies; 10+ messages in thread
From: tndave @ 2017-03-08 19:30 UTC (permalink / raw)
  To: intel-wired-lan



On 03/08/2017 07:39 AM, Alexander Duyck wrote:
> On Tue, Mar 7, 2017 at 3:43 PM, tndave <tushar.n.dave@oracle.com>
> wrote:
>> Hi,
>>
>> I have few questions regarding ixgbe flow director. As per my
>> understanding flow director in ixgbe can work in 2 exclusive ways,
>>  a. Using ATR filters - where flow director is setup in HW by
>> driver identifying transmit traffic. And based on that, receive
>> traffic of the same flow get assigned/directed to same queue.
>
> So ATR for ixgbe uses the Flow Director signature filters. Basically
> the signature filters are purely hash based filters.  The easiest way
> to think of it is it is essentially a beefed up version of RSS.
Alex,

Thanks for the info.
>
>> b. Perfect filter, where user can manually program flow director
>> using ethtool so that receive packets gets directed to specified
>> rx queue (depending on on how ethtool flow-type and action etc,.);
>> But with perfect filters there is no intelligence involved alike
>> ATR has on identifying transit, right?
>
> You are right.  The perfect match filters are the ones we configure
> via ethtool.  You are correct in that ATR logic is not involved so
> there is no matching up an Rx flow to a Tx flow.
>
>> Few question regarding ixgbe ATR, 1. does ATR works in case if
>> protocol is UDP? (Based on the current ixgbe_atr() it only
>> supports TCP)
>
> It could, but the software for doing ATR flow identification,
> ixgbe_atr(), only works on TCP.  The reasoning behind it is that Flow
> Director doesn't filter fragmented frames and UDP can be fragmented.
So we could just add code in ixgbe_atr() for non-fragmented udp packets!
However question is if it is going to work w.r.t ATR? TCP is connected
stream vs udp is stateless and single udp socket can talk to multiple
endpoints.

>
>> 2. Does ATR flow director can be programmed using ethtool? (As per
>> my understanding only perfect filter can be programmed from
>> ethtool, is that so?)
>
> You can enable/disable the ATR filters via the NTUPLE feaure flag.
> Basically it toggles between ATR mode, and NTUPLE mode.  In NTUPLE
> mode the perfect filters are enabled and can be configured via
> ethtool.
Got it.

Thanks.

-Tushar
>
>> Thanks in advance, -Tushar
>
> Hope that helps.
>
> - Alex
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Intel-wired-lan] Question on ixgbe flow director
  2017-03-08 19:30     ` tndave
@ 2017-03-08 21:03       ` Alexander Duyck
  -1 siblings, 0 replies; 10+ messages in thread
From: Alexander Duyck @ 2017-03-08 21:03 UTC (permalink / raw)
  To: tndave; +Cc: intel-wired-lan, netdev, Sowmini Varadhan

On Wed, Mar 8, 2017 at 11:30 AM, tndave <tushar.n.dave@oracle.com> wrote:
>
>
> On 03/08/2017 07:39 AM, Alexander Duyck wrote:
>>
>> On Tue, Mar 7, 2017 at 3:43 PM, tndave <tushar.n.dave@oracle.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I have few questions regarding ixgbe flow director. As per my
>>> understanding flow director in ixgbe can work in 2 exclusive ways,
>>>  a. Using ATR filters - where flow director is setup in HW by
>>> driver identifying transmit traffic. And based on that, receive
>>> traffic of the same flow get assigned/directed to same queue.
>>
>>
>> So ATR for ixgbe uses the Flow Director signature filters. Basically
>> the signature filters are purely hash based filters.  The easiest way
>> to think of it is it is essentially a beefed up version of RSS.
>
> Alex,
>
> Thanks for the info.
>>
>>
>>> b. Perfect filter, where user can manually program flow director
>>> using ethtool so that receive packets gets directed to specified
>>> rx queue (depending on on how ethtool flow-type and action etc,.);
>>> But with perfect filters there is no intelligence involved alike
>>> ATR has on identifying transit, right?
>>
>>
>> You are right.  The perfect match filters are the ones we configure
>> via ethtool.  You are correct in that ATR logic is not involved so
>> there is no matching up an Rx flow to a Tx flow.
>>
>>> Few question regarding ixgbe ATR, 1. does ATR works in case if
>>> protocol is UDP? (Based on the current ixgbe_atr() it only
>>> supports TCP)
>>
>>
>> It could, but the software for doing ATR flow identification,
>> ixgbe_atr(), only works on TCP.  The reasoning behind it is that Flow
>> Director doesn't filter fragmented frames and UDP can be fragmented.
>
> So we could just add code in ixgbe_atr() for non-fragmented udp packets!
> However question is if it is going to work w.r.t ATR? TCP is connected
> stream vs udp is stateless and single udp socket can talk to multiple
> endpoints.

Right so the Tx based approach for UDP also probably won't work
because there isn't a symmetric set of endpoints used for most UDP
flows.  For example with TCP you have a fixed set of source and
destination ports that you can swap and get the opposite direction.
The same isn't true for UDP.  You can end up with UDP using a random
source port and sending to the same fixed destination port on both
ends.

You might look at the hardware RPS offload that some of the other
drivers out there support that allow for hardware accelerated RFS
offload.  Something like that might work for your needs if you are
needing to route UDP.

>>
>>> 2. Does ATR flow director can be programmed using ethtool? (As per
>>> my understanding only perfect filter can be programmed from
>>> ethtool, is that so?)
>>
>>
>> You can enable/disable the ATR filters via the NTUPLE feaure flag.
>> Basically it toggles between ATR mode, and NTUPLE mode.  In NTUPLE
>> mode the perfect filters are enabled and can be configured via
>> ethtool.
>
> Got it.
>
> Thanks.
>
> -Tushar
>
>>
>>> Thanks in advance, -Tushar
>>
>>
>> Hope that helps.
>>
>> - Alex
>>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Intel-wired-lan] Question on ixgbe flow director
@ 2017-03-08 21:03       ` Alexander Duyck
  0 siblings, 0 replies; 10+ messages in thread
From: Alexander Duyck @ 2017-03-08 21:03 UTC (permalink / raw)
  To: intel-wired-lan

On Wed, Mar 8, 2017 at 11:30 AM, tndave <tushar.n.dave@oracle.com> wrote:
>
>
> On 03/08/2017 07:39 AM, Alexander Duyck wrote:
>>
>> On Tue, Mar 7, 2017 at 3:43 PM, tndave <tushar.n.dave@oracle.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I have few questions regarding ixgbe flow director. As per my
>>> understanding flow director in ixgbe can work in 2 exclusive ways,
>>>  a. Using ATR filters - where flow director is setup in HW by
>>> driver identifying transmit traffic. And based on that, receive
>>> traffic of the same flow get assigned/directed to same queue.
>>
>>
>> So ATR for ixgbe uses the Flow Director signature filters. Basically
>> the signature filters are purely hash based filters.  The easiest way
>> to think of it is it is essentially a beefed up version of RSS.
>
> Alex,
>
> Thanks for the info.
>>
>>
>>> b. Perfect filter, where user can manually program flow director
>>> using ethtool so that receive packets gets directed to specified
>>> rx queue (depending on on how ethtool flow-type and action etc,.);
>>> But with perfect filters there is no intelligence involved alike
>>> ATR has on identifying transit, right?
>>
>>
>> You are right.  The perfect match filters are the ones we configure
>> via ethtool.  You are correct in that ATR logic is not involved so
>> there is no matching up an Rx flow to a Tx flow.
>>
>>> Few question regarding ixgbe ATR, 1. does ATR works in case if
>>> protocol is UDP? (Based on the current ixgbe_atr() it only
>>> supports TCP)
>>
>>
>> It could, but the software for doing ATR flow identification,
>> ixgbe_atr(), only works on TCP.  The reasoning behind it is that Flow
>> Director doesn't filter fragmented frames and UDP can be fragmented.
>
> So we could just add code in ixgbe_atr() for non-fragmented udp packets!
> However question is if it is going to work w.r.t ATR? TCP is connected
> stream vs udp is stateless and single udp socket can talk to multiple
> endpoints.

Right so the Tx based approach for UDP also probably won't work
because there isn't a symmetric set of endpoints used for most UDP
flows.  For example with TCP you have a fixed set of source and
destination ports that you can swap and get the opposite direction.
The same isn't true for UDP.  You can end up with UDP using a random
source port and sending to the same fixed destination port on both
ends.

You might look at the hardware RPS offload that some of the other
drivers out there support that allow for hardware accelerated RFS
offload.  Something like that might work for your needs if you are
needing to route UDP.

>>
>>> 2. Does ATR flow director can be programmed using ethtool? (As per
>>> my understanding only perfect filter can be programmed from
>>> ethtool, is that so?)
>>
>>
>> You can enable/disable the ATR filters via the NTUPLE feaure flag.
>> Basically it toggles between ATR mode, and NTUPLE mode.  In NTUPLE
>> mode the perfect filters are enabled and can be configured via
>> ethtool.
>
> Got it.
>
> Thanks.
>
> -Tushar
>
>>
>>> Thanks in advance, -Tushar
>>
>>
>> Hope that helps.
>>
>> - Alex
>>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Intel-wired-lan] Question on ixgbe flow director
  2017-03-08 21:03       ` Alexander Duyck
@ 2017-03-08 22:56         ` tndave
  -1 siblings, 0 replies; 10+ messages in thread
From: tndave @ 2017-03-08 22:56 UTC (permalink / raw)
  To: Alexander Duyck; +Cc: intel-wired-lan, netdev, Sowmini Varadhan



On 03/08/2017 01:03 PM, Alexander Duyck wrote:
> On Wed, Mar 8, 2017 at 11:30 AM, tndave <tushar.n.dave@oracle.com> wrote:
>>
>>
>> On 03/08/2017 07:39 AM, Alexander Duyck wrote:
>>>
>>> On Tue, Mar 7, 2017 at 3:43 PM, tndave <tushar.n.dave@oracle.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have few questions regarding ixgbe flow director. As per my
>>>> understanding flow director in ixgbe can work in 2 exclusive ways,
>>>>  a. Using ATR filters - where flow director is setup in HW by
>>>> driver identifying transmit traffic. And based on that, receive
>>>> traffic of the same flow get assigned/directed to same queue.
>>>
>>>
>>> So ATR for ixgbe uses the Flow Director signature filters. Basically
>>> the signature filters are purely hash based filters.  The easiest way
>>> to think of it is it is essentially a beefed up version of RSS.
>>
>> Alex,
>>
>> Thanks for the info.
>>>
>>>
>>>> b. Perfect filter, where user can manually program flow director
>>>> using ethtool so that receive packets gets directed to specified
>>>> rx queue (depending on on how ethtool flow-type and action etc,.);
>>>> But with perfect filters there is no intelligence involved alike
>>>> ATR has on identifying transit, right?
>>>
>>>
>>> You are right.  The perfect match filters are the ones we configure
>>> via ethtool.  You are correct in that ATR logic is not involved so
>>> there is no matching up an Rx flow to a Tx flow.
>>>
>>>> Few question regarding ixgbe ATR, 1. does ATR works in case if
>>>> protocol is UDP? (Based on the current ixgbe_atr() it only
>>>> supports TCP)
>>>
>>>
>>> It could, but the software for doing ATR flow identification,
>>> ixgbe_atr(), only works on TCP.  The reasoning behind it is that Flow
>>> Director doesn't filter fragmented frames and UDP can be fragmented.
>>
>> So we could just add code in ixgbe_atr() for non-fragmented udp packets!
>> However question is if it is going to work w.r.t ATR? TCP is connected
>> stream vs udp is stateless and single udp socket can talk to multiple
>> endpoints.
>
> Right so the Tx based approach for UDP also probably won't work
> because there isn't a symmetric set of endpoints used for most UDP
> flows.  For example with TCP you have a fixed set of source and
> destination ports that you can swap and get the opposite direction.
> The same isn't true for UDP.  You can end up with UDP using a random
> source port and sending to the same fixed destination port on both
> ends.
>
> You might look at the hardware RPS offload that some of the other
> drivers out there support that allow for hardware accelerated RFS
> offload.  Something like that might work for your needs if you are
> needing to route UDP.
Okay. Thanks Alex.

-Tushar
>
>>>
>>>> 2. Does ATR flow director can be programmed using ethtool? (As per
>>>> my understanding only perfect filter can be programmed from
>>>> ethtool, is that so?)
>>>
>>>
>>> You can enable/disable the ATR filters via the NTUPLE feaure flag.
>>> Basically it toggles between ATR mode, and NTUPLE mode.  In NTUPLE
>>> mode the perfect filters are enabled and can be configured via
>>> ethtool.
>>
>> Got it.
>>
>> Thanks.
>>
>> -Tushar
>>
>>>
>>>> Thanks in advance, -Tushar
>>>
>>>
>>> Hope that helps.
>>>
>>> - Alex
>>>
>>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Intel-wired-lan] Question on ixgbe flow director
@ 2017-03-08 22:56         ` tndave
  0 siblings, 0 replies; 10+ messages in thread
From: tndave @ 2017-03-08 22:56 UTC (permalink / raw)
  To: intel-wired-lan



On 03/08/2017 01:03 PM, Alexander Duyck wrote:
> On Wed, Mar 8, 2017 at 11:30 AM, tndave <tushar.n.dave@oracle.com> wrote:
>>
>>
>> On 03/08/2017 07:39 AM, Alexander Duyck wrote:
>>>
>>> On Tue, Mar 7, 2017 at 3:43 PM, tndave <tushar.n.dave@oracle.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have few questions regarding ixgbe flow director. As per my
>>>> understanding flow director in ixgbe can work in 2 exclusive ways,
>>>>  a. Using ATR filters - where flow director is setup in HW by
>>>> driver identifying transmit traffic. And based on that, receive
>>>> traffic of the same flow get assigned/directed to same queue.
>>>
>>>
>>> So ATR for ixgbe uses the Flow Director signature filters. Basically
>>> the signature filters are purely hash based filters.  The easiest way
>>> to think of it is it is essentially a beefed up version of RSS.
>>
>> Alex,
>>
>> Thanks for the info.
>>>
>>>
>>>> b. Perfect filter, where user can manually program flow director
>>>> using ethtool so that receive packets gets directed to specified
>>>> rx queue (depending on on how ethtool flow-type and action etc,.);
>>>> But with perfect filters there is no intelligence involved alike
>>>> ATR has on identifying transit, right?
>>>
>>>
>>> You are right.  The perfect match filters are the ones we configure
>>> via ethtool.  You are correct in that ATR logic is not involved so
>>> there is no matching up an Rx flow to a Tx flow.
>>>
>>>> Few question regarding ixgbe ATR, 1. does ATR works in case if
>>>> protocol is UDP? (Based on the current ixgbe_atr() it only
>>>> supports TCP)
>>>
>>>
>>> It could, but the software for doing ATR flow identification,
>>> ixgbe_atr(), only works on TCP.  The reasoning behind it is that Flow
>>> Director doesn't filter fragmented frames and UDP can be fragmented.
>>
>> So we could just add code in ixgbe_atr() for non-fragmented udp packets!
>> However question is if it is going to work w.r.t ATR? TCP is connected
>> stream vs udp is stateless and single udp socket can talk to multiple
>> endpoints.
>
> Right so the Tx based approach for UDP also probably won't work
> because there isn't a symmetric set of endpoints used for most UDP
> flows.  For example with TCP you have a fixed set of source and
> destination ports that you can swap and get the opposite direction.
> The same isn't true for UDP.  You can end up with UDP using a random
> source port and sending to the same fixed destination port on both
> ends.
>
> You might look at the hardware RPS offload that some of the other
> drivers out there support that allow for hardware accelerated RFS
> offload.  Something like that might work for your needs if you are
> needing to route UDP.
Okay. Thanks Alex.

-Tushar
>
>>>
>>>> 2. Does ATR flow director can be programmed using ethtool? (As per
>>>> my understanding only perfect filter can be programmed from
>>>> ethtool, is that so?)
>>>
>>>
>>> You can enable/disable the ATR filters via the NTUPLE feaure flag.
>>> Basically it toggles between ATR mode, and NTUPLE mode.  In NTUPLE
>>> mode the perfect filters are enabled and can be configured via
>>> ethtool.
>>
>> Got it.
>>
>> Thanks.
>>
>> -Tushar
>>
>>>
>>>> Thanks in advance, -Tushar
>>>
>>>
>>> Hope that helps.
>>>
>>> - Alex
>>>
>>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-03-08 22:59 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-07 23:43 Question on ixgbe flow director tndave
2017-03-07 23:43 ` [Intel-wired-lan] " tndave
2017-03-08 15:39 ` Alexander Duyck
2017-03-08 15:39   ` Alexander Duyck
2017-03-08 19:30   ` tndave
2017-03-08 19:30     ` tndave
2017-03-08 21:03     ` Alexander Duyck
2017-03-08 21:03       ` Alexander Duyck
2017-03-08 22:56       ` tndave
2017-03-08 22:56         ` tndave

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.