Open ChenYahui2019 opened 4 years ago
@ChenYahui2019 If you mean, that you already have DPDK process that set up the rings and now you want to reuse those rings within the NFF-Go process, then currently such functionality is unavailable. Can you please elaborate on the use-case why do you need to reuse instead of doing it inside NFF-Go app?
@aregm Thx. This is my scenario:
I add a dpdkring port in ovs-dpdk using cmd
ovs-vsctl add-port dpdk-br0 dpdkr0 -- set interface dpdkr0 typ=dpdkr
and configure a mirror policy mirroring all the ovs-dpdk traffic to dpkr0.
Then I launch another pmd with parameter --proc-type=secondary
to capture packet from dpdkr0 which will lookup dpdkr0 ring.
I have wrote this API, but I can not make PR for step 5 below fail with "remote: Repository not found".
@ChenYahui2019 Did you fork the nff-go repository?
@leoluk How to fork? Git do not have sub-commad fork.
It's a feature specific to GitHub
@leoluk Thx a lot. I made a PR successfully just now.
@leoluk Thx a lot. I made a PR successfully just now. https://github.com/intel-go/nff-go/pull/672
May I ask when will this commit to master?
Hello @ChenYahui2019 I merged all develop changes into master and published new release 0.9.2 with them.
@gshimansky Thank for your response. I have another question, for my scenario I just want to use DPDK's API with golang version such as DequeueBurst
EnqueueBurst
, could we change file directory internal/low
to low
or using linkname to export internal
API? If this ok, I would make a PR.
Low used to be on the upper level but was moved into internal in #592. I don't think that we need to expose low level functions because they aren't meant to be used by user programs. Can you explain how you intend to use them? You can always write your own package inside of nff-go framework or modify for your needs existing code which uses low API.
Here my scene below: https://github.com/intel-go/nff-go/issues/665#issuecomment-554175406
@ChenYahui2019 the idea of NFF-Go was to hide all the complexity with dealing with low-level hardware and provide abstractions, where you can focus on the packet processing logic itself. Exposing all that as an API is going against that concept. Feel free to expose them in your project from internals. We do not expose rings directly as they are controlled by the scheduler, and interfering with it from the lower level will break the logic.
Currently,
rte_ring_create
has been provided. But what our project need isrte_ring_lookup
getting existed ring.