DPDK patches and discussions
 help / color / mirror / Atom feed
From: Moon-Sang Lee <sang0627@gmail.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [Q] l2fwd in examples directory
Date: Mon, 19 Oct 2015 16:51:28 +0900	[thread overview]
Message-ID: <CAACK=Xc=0PcvRHVeAgghDypuUPGHZkyZ_AHJXanYNrJxeob7sg@mail.gmail.com> (raw)
In-Reply-To: <CAACK=Xd4ZmO69k-PVTmKUXYxPSQybxD063qT+O4apdmEgYYp8Q@mail.gmail.com>

Let me clarify my mixed stuffs.

My processor is L5520, family 6, model 26 that is based on Nehalem
microarchitecture
according to wikipedia (
https://en.wikipedia.org/wiki/Nehalem_(microarchitecture)),
it does not have PCI interface on chipset.

Therefore, "rte_eth_dev_socket_id(portid) always returns -1"  seems no
problem.
My understanding of the lstopo result might be wrong.

Thanks anyway.




On Mon, Oct 19, 2015 at 4:39 PM, Moon-Sang Lee <sang0627@gmail.com> wrote:

>
> My NUT has Xeon L5520 that is based on Nehalem microarchitecture.
> Does Nehalem supports PCIe interface on chipset?
>
> Anyhow, 'lstopo' shows as below and it seems that my PCI devices are
> connected to socket #0.
> I'm still wondering why rte_eth_dev_socket_id(portid) always returns -1.
>
> mslee@myhost:~$ lstopo
> Machine (31GB)
>   NUMANode L#0 (P#0 16GB) + Socket L#0 + L3 L#0 (8192KB)
>     L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
>       PU L#0 (P#0)
>       PU L#1 (P#8)
>     L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
>       PU L#2 (P#2)
>       PU L#3 (P#10)
>     L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2
>       PU L#4 (P#4)
>       PU L#5 (P#12)
>     L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3
>       PU L#6 (P#6)
>       PU L#7 (P#14)
>   NUMANode L#1 (P#1 16GB) + Socket L#1 + L3 L#1 (8192KB)
>     L2 L#4 (256KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4
>       PU L#8 (P#1)
>       PU L#9 (P#9)
>     L2 L#5 (256KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5
>       PU L#10 (P#3)
>       PU L#11 (P#11)
>     L2 L#6 (256KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6
>       PU L#12 (P#5)
>       PU L#13 (P#13)
>     L2 L#7 (256KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7
>       PU L#14 (P#7)
>       PU L#15 (P#15)
>   HostBridge L#0
>     PCIBridge
>       PCI 14e4:163b
>         Net L#0 "em1"
>       PCI 14e4:163b
>         Net L#1 "em2"
>     PCIBridge
>       PCI 1000:0058
>         Block L#2 "sda"
>         Block L#3 "sdb"
>     PCIBridge
>       PCIBridge
>         PCIBridge
>           PCI 8086:10e8
>           PCI 8086:10e8
>         PCIBridge
>           PCI 8086:10e8
>           PCI 8086:10e8
>     PCIBridge
>       PCI 102b:0532
>     PCI 8086:3a20
>     PCI 8086:3a26
>       Block L#4 "sr0"
> mslee@myhost:~$
>
>
>
> On Sun, Oct 18, 2015 at 2:51 PM, Moon-Sang Lee <sang0627@gmail.com> wrote:
>
>>
>> thanks bruce.
>>
>> I didn't know that PCI slots have direct socket affinity.
>> is it static or configurable through PCI configuration space?
>> well, my NUT, two node NUMA, seems always returns -1 on calling
>> rte_eth_dev_socket_id(portid) whenever portid is 0, 1, or other values.
>> I appreciate if you explain more about getting the affinity.
>>
>> p.s.
>> I'm using intel Xeon processor and 1G NIC(82576).
>>
>>
>>
>>
>> On Fri, Oct 16, 2015 at 10:43 PM, Bruce Richardson <
>> bruce.richardson@intel.com> wrote:
>>
>>> On Thu, Oct 15, 2015 at 11:08:57AM +0900, Moon-Sang Lee wrote:
>>> > There is codes as below in examples/l2fwd/main.c and I think
>>> > rte_eth_dev_socket_id(portid)
>>> > always returns -1(SOCKET_ID_ANY) since there is no association code
>>> between
>>> > port and
>>> > lcore in the example codes.
>>>
>>> Can you perhaps clarify what you mean here. On modern NUMA systems, such
>>> as those
>>> from Intel :-), the PCI slots are directly connected to the CPU sockets,
>>> so the
>>> ethernet ports do indeed have a direct NUMA affinity. It's not something
>>> that
>>> the app needs to specify.
>>>
>>> /Bruce
>>>
>>> > (i.e. I need to find a matching lcore from
>>> > lcore_queue_conf[] with portid
>>> > and call rte_lcore_to_socket_id(lcore_id).)
>>> >
>>> >         /* init one RX queue */
>>> >         fflush(stdout);
>>> >         ret = rte_eth_rx_queue_setup(portid, 0, nb_rxd,
>>> >                          rte_eth_dev_socket_id(portid),
>>> >                          NULL,
>>> >                          l2fwd_pktmbuf_pool);
>>> >         if (ret < 0)
>>> >             rte_exit(EXIT_FAILURE, "rte_eth_rx_queue_setup:err=%d,
>>> > port=%u\n",
>>> >                   ret, (unsigned) portid);
>>> >
>>> > It works fine even though memory is allocated in different NUMA node.
>>> But I
>>> > wonder there is
>>> > a DPDK API that associates inlcore to port internally thus
>>> > rte_eth_devices[portid].pci_dev->numa_node
>>> > contains proper node.
>>> >
>>> >
>>> > --
>>> > Moon-Sang Lee, SW Engineer
>>> > Email: sang0627@gmail.com
>>> > Wisdom begins in wonder. *Socrates*
>>>
>>
>>
>>
>> --
>> Moon-Sang Lee, SW Engineer
>> Email: sang0627@gmail.com
>> Wisdom begins in wonder. *Socrates*
>>
>
>
>
> --
> Moon-Sang Lee, SW Engineer
> Email: sang0627@gmail.com
> Wisdom begins in wonder. *Socrates*
>



-- 
Moon-Sang Lee, SW Engineer
Email: sang0627@gmail.com
Wisdom begins in wonder. *Socrates*

  reply	other threads:[~2015-10-19  7:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-15  2:08 Moon-Sang Lee
2015-10-15  2:08 ` Moon-Sang Lee
2015-10-16 13:43   ` Bruce Richardson
2015-10-18  5:51     ` Moon-Sang Lee
2015-10-19  7:39       ` Moon-Sang Lee
2015-10-19  7:51         ` Moon-Sang Lee [this message]
2015-10-19  9:34         ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAACK=Xc=0PcvRHVeAgghDypuUPGHZkyZ_AHJXanYNrJxeob7sg@mail.gmail.com' \
    --to=sang0627@gmail.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).