DPDK usage discussions
 help / color / mirror / Atom feed
* [dpdk-users] RSS : All fragments to same Recv queue
@ 2017-03-08 15:50 Shyam Shrivastav
  2017-03-09  2:18 ` Stephen Hemminger
  0 siblings, 1 reply; 3+ messages in thread
From: Shyam Shrivastav @ 2017-03-08 15:50 UTC (permalink / raw)
  To: users; +Cc: Shyam Shrivastav

Hi

We want to use RSS supported by intel 82599 NIC, with one lcore running on
each processor and handling one receive queue. All fragments of an ipv4
packet need to go to same receive queue and handled by same lcore for
lockless reassembly. Looks like Intel  82599 supports RSS IPv4 hashing
using just source and dest address fields and that should put all fragments
on same queue ( can be enabled by ETH_RSS_IPV4 in rte_eth_rss_conf->rs_hf).
Please let me know whether my understanding is correct.

Thanks
Shyam

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

* Re: [dpdk-users] RSS : All fragments to same Recv queue
  2017-03-08 15:50 [dpdk-users] RSS : All fragments to same Recv queue Shyam Shrivastav
@ 2017-03-09  2:18 ` Stephen Hemminger
  2017-03-09  4:55   ` Shyam Shrivastav
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2017-03-09  2:18 UTC (permalink / raw)
  To: Shyam Shrivastav; +Cc: users

On Wed, 8 Mar 2017 21:20:57 +0530
Shyam Shrivastav <shrivastav.shyam@gmail.com> wrote:

> Hi
> 
> We want to use RSS supported by intel 82599 NIC, with one lcore running on
> each processor and handling one receive queue. All fragments of an ipv4
> packet need to go to same receive queue and handled by same lcore for
> lockless reassembly. Looks like Intel  82599 supports RSS IPv4 hashing
> using just source and dest address fields and that should put all fragments
> on same queue ( can be enabled by ETH_RSS_IPV4 in rte_eth_rss_conf->rs_hf).
> Please let me know whether my understanding is correct.
> 
> Thanks
> Shyam

Yes as long as you keep port numbers out of the RSS hash it should work,
but you may have to deal with fragments arriving over different paths.
There is nothing in IP architecture that prevents multi-pathing.

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

* Re: [dpdk-users] RSS : All fragments to same Recv queue
  2017-03-09  2:18 ` Stephen Hemminger
@ 2017-03-09  4:55   ` Shyam Shrivastav
  0 siblings, 0 replies; 3+ messages in thread
From: Shyam Shrivastav @ 2017-03-09  4:55 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: users

Thanks, multipath is taken care of by upstream router so that all fragments
of a packet are injected on same interface ...

On Thu, Mar 9, 2017 at 7:48 AM, Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Wed, 8 Mar 2017 21:20:57 +0530
> Shyam Shrivastav <shrivastav.shyam@gmail.com> wrote:
>
> > Hi
> >
> > We want to use RSS supported by intel 82599 NIC, with one lcore running
> on
> > each processor and handling one receive queue. All fragments of an ipv4
> > packet need to go to same receive queue and handled by same lcore for
> > lockless reassembly. Looks like Intel  82599 supports RSS IPv4 hashing
> > using just source and dest address fields and that should put all
> fragments
> > on same queue ( can be enabled by ETH_RSS_IPV4 in
> rte_eth_rss_conf->rs_hf).
> > Please let me know whether my understanding is correct.
> >
> > Thanks
> > Shyam
>
> Yes as long as you keep port numbers out of the RSS hash it should work,
> but you may have to deal with fragments arriving over different paths.
> There is nothing in IP architecture that prevents multi-pathing.
>

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

end of thread, other threads:[~2017-03-09  4:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-08 15:50 [dpdk-users] RSS : All fragments to same Recv queue Shyam Shrivastav
2017-03-09  2:18 ` Stephen Hemminger
2017-03-09  4:55   ` Shyam Shrivastav

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).