Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: Ib1b3d54f9cb8e4284eee7ed0998e96370762a17e
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: Idd72b593504139ac9d42c33767f8a18395b2cc87
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Following messages are now handled by PROX
- router_solicitation
- neighbour_solicitation
- router_advertisement
- neighbour_advertisement
The following parameters are supported (through the PROX config file)
- sub mode=ndp
This will enable handling of router and neighbour solicitation
and advertisement.
- local ipv6=xxxx:xxxx:xxxxx:xxxx:xxxx:xxxx:xxxx:xxxx
This will configure the local IPv6 address of the port.
This parameter is optional. If not specified, the local IPv6
will be calculated from the EUI.
- global ipv6=xxxx:xxxx:xxxxx:xxxx:xxxx:xxxx:xxxx:xxxx
This will configure the global IPv6 address of the port.
This parameter is optional. If not specified, the global IPv6
will be calculated from the EUI and the router prefix received
from the router.
- ipv6 router=yes
This will cause the core to behave as an IPv6 router
i.e. it will generate Router Advertisement messages
This is only useful in back to back cases, when no real
IPv6 router is present in the setup.
- router prefix=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
The router prefix usedin the router advertisement
The prefix will be used by the node to build an IPv6 global
address in cases none were configured.
"Unsollicited NA" parameter has been added within the core/task section.
If set to yes (Unsollicited NA=yes), then an unsollicited neighbour
Advertisement is sent at startup
A same core/task cannot support both l3 and ndp mode.
Those messages will be generated or handled when submode
is set to "ndp":
- neighbour sollicitation
- neighbour advertisement
- router sollicitation
- router advertisement
An example configuration is provided: config/ipv6.cfg in which
port 0 / core 1 plays the role of the generator and port 1 /
core 2 plays the role of the swap.
Change-Id: Id0ab32d384448b4cf767fb4a1c486fc023f4f395
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
For kernel supported devices, add for vlan tag support
This can be configured through port parameter:
vlan tag=<vlan tag>
If this parameter is set, a vlan tagged interface is created
on top of the tap device
This is only supported for vdev tap devices
When sending (untagged) packet to the tap device (through socket)
the tap should react in sending tagged packet
Note that receiving in L3 mode (w/o tap support) a tagged packet
is not yet supported.
Change-Id: I363fa2f8d2341ac41ef23620222ece1d944bf336
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Through this commit BGP messages are forwarded to tap device
Netlink messages are enabled to receive route Updates.
In addition, generating tasks can also specify a routing table
which will be used when sending packets
The routes initialized by the routing table can be changed through
the reception of BGP messages
Change-Id: I187ba9a921885cbc9b209aae5fb654309e3388b8
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Through this commit ARP and ICMP messages are forwarded to the kernel
when vdev tap devices are enabled, as well as PROX l3 mode.
ICMP support has also been added to master (i.e. PROX L3 mode) and to
swap (so when L3 submode is not enabled).
Change-Id: Ie6bf52cbae7171bfca041ff18651d4ec866f44cd
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Improve PROX generator performance by pre-calculating bytes_to_tsc.
This improvement is only implemented for non-pcap
generator, where only few different packet sizes are usually generated.
This change might have a negative performance impact in some cases, if
many different packet sizes are generated, resulting in higher memory usage.
This is the case for instance if random is applied to packet size.
In addition, simplified the rx path, receiving now only MAX_PKT_BURST packets
per handle loop.
Before we were trying to empty the NIC looping on RX packets, ending up
with many rx packets per handle loop. This was used to determine an lower bound
for the time the packet was received.
We now set the lower bound when less than MAX_PKT_BURST has been received.
Change-Id: I1ce813d7e4ac1577ea412c590add5d6f94b36ec7
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
When performing some zero packet loss performance testing on dataplane, it
is important (not) to count non dataplane packets. For instance, one might
receive uexpected packets from a switch, or ARP packets. Or one might need
to transmit ARP packets. Such packets should not be counted as dataplane
packets as for thse packets there is no 1:1 mapping between transmitted
packets and received packets.
To support this, the counters reporting numbers of transmitted and received
packets remain unchanged but two new counters have been added to PROX,
counting respectively number of received and number of transmitted
non-dataplane packets.
On RX side, packets are counsidered as non-dataplane if being ARP or if
they do not countain the proper signature
On TX side, ARP packets are not considered as dataplane packets.
This feature requires configuration of signature.
"dp core stats" command has been added
Change-Id: I98e113cd02f36d540383d343a433592867ad86a9
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
In some (rare) modes, more than 64 packets can be received through
one rx function. This is for instance the case of the lat mode.
Change-Id: Ie733c927a8e116c679c464f2551768185ef85366
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
There were two issues identified in dump receive packets
- when the receive packets was going to be dropped (and not transmitted),
it was also printed as TX[255].
- a potential crash when using the dump function with modes like
lat which can receive more than MAX_RING_BURST.
Those issues have been fixed.
Change-Id: Ia2297539d64961a211389d68e3c9c6280472243c
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
PROX can stack different RX functions, so that they are executed
after each other.
This feature is for instance used to dump packets or to print
distribution of receive packets, without influencing the performance
of the rx functions when no dump or print is needed.
The previous implementation was wrong and causing some of the stacked
functions not to be executed. This was causing for instance issues
in latency measurement after enabling dumping packets.
Change-Id: I766b8ee8e8852fa17cdaf60ee6e1fec0dc98c719
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: Ie6d4e7ce22c27967117a446626f5923643397812
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
JIRA: SAMPLEVNF-55
PROX is a DPDK-based application implementing Telco use-cases such as
a simplified BRAS/BNG, light-weight AFTR... It also allows configuring
finer grained network functions like QoS, Routing, load-balancing...
(We are moving PROX version v039 to sampleVNF
https://01.org/intel-data-plane-performance-demonstrators/prox-overview)
Change-Id: Ia3cb02cf0e49ac5596e922c197ff7e010293d033
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
|