dpdk PMDs implement stats_reset of rte_ethdev.h:struct eth_dev_ops in order to reset port statistics.
PMD vmxnet3 doesn't register it under
static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
...
.stats_get = vmxnet3_dev_stats_get,
.xstats_get_names = vmxnet3_dev_xstats_get_names,
.xstats_get = vmxnet3_dev_xstats_get,
...
There are only get functions, but no reset.
Does it mean vmxnet3 cannot clear port statistics?
Is there a way to implement it?
The strange thing is that no one complains it over the internet. Looks like I'm the only one that needs it.
dpdk versions 17.11.1, dpdk-stable-18.02.2
Does it mean vmxnet3 cannot clear port statistics?
Yes, the PMD does not implement the functionality.
Is there a way to implement it?
We can workaround it in the code or implement the same workaround in the PMD and send a patch to dev#dpdk.org as described here: https://www.dpdk.org/contribute/
The idea behind the workaround is that we can store base stats:
stats_reset() {
base_stats = eth_stats_get()
}
stats_get() {
return etc_stats_get() - base_stats
}
Feel free to ask if it is not clear.
Related
I'd like to understand how to transmit the contents of a C++ class between processes or across a network.
I'm reading the Google Protobuf tutorial:
https://developers.google.com/protocol-buffers/docs/cpptutorial
and it seems you must create an abstracted, non-C++ interface to represent your class:
syntax = "proto2";
package tutorial;
message Person {
optional string name = 1;
optional int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
}
However, I'd prefer to specify my class via C++ code (rather than the abstraction) and just add something like serialize() and deserialize() methods.
Is this possible with Google Protobuf? Or is this how Protobuf works and I'd need to use a different serialization technique?
UPDATE
The reason for this is I don't want to have to maintain two interfaces. I'd prefer to have one C++ class, update it and not have to worry about a second .proto interface/definition. Code maintainability.
That's how Protobuf works. You have to use something else if you want to serialize your manually-written C++ classes. However, I'm not sure you really want that, because you then will have to either restrict yourself to very simple fields with no invariants (just like in Protobuf) or write custom (de)serialization logic yourself.
You could make a simple protocol buffer to hold binary information, but it sort of breaks the point of using Protocol buffers.
You can sort of cheat the system by using SerializeToString() and ParseFromString() to simply serialize binary information into a string.
There is also SerializeToOstream() and ParseFromIstream().
The real value of protocol buffers is being able to use messages across programs, systems and languages while using a single definition. If you aren't making messages using the protocol they've defined; this is more work than simply using native C++ capabilities.
Apache Thrift is one of the more popular choices for an opensource RPC frameworks (gRPC is also one that gets lot of tracktion since release into the open).
In my setup in c++ Im using a TMultiplexedProcessor. I guess this could be any TProcessor for that matter since Im just interested in printing whatever is sent.
This has a method called:
bool process(std::shared_ptr<protocol::TProtocol> in,
std::shared_ptr<protocol::TProtocol> out,
void* connectionContext) override {
My idea was to override this again, so that I could print the in argument - but how can I write TProtocol to output ? (at a glance, it does not seem straightforward to serialize into a string)
I get a feeling there maybe is some other or an easier method. So my question is how can I dump all messages recieved via thrift (for debugging purpose) ?
There's TProtocolTap and TDebugProtocol.
Usage example can be found in thrift_dump.cpp:
shared_ptr<TProtocol> iprot(new TBinaryProtocol(itrans));
shared_ptr<TProtocol> oprot(
new TDebugProtocol(
shared_ptr<TTransport>(new TBufferedTransport(
shared_ptr<TTransport>(new TFDTransport(STDOUT_FILENO))))));
TProtocolTap tap(iprot, oprot);
std::string name;
TMessageType messageType;
int32_t seqid;
for (;;) {
tap.readMessageBegin(name, messageType, seqid);
tap.skip(T_STRUCT);
tap.readMessageEnd();
}
I'm trying to upgrade my AutoFFI project by making it more elegant and use Clang's ASTMatchers more extensively. I'd like to create a matcher that filters on the file path that was specified. Is it possible to do such a thing, or do I need to add custom logic outside of the matcher for this to work? As far as I can see, there's no way to get the SourceManager and use it to create a FullSourceLoc, but maybe I'm missing something.
Some relevant links:
https://clang.llvm.org/doxygen/classclang_1_1FullSourceLoc.html
https://github.com/llvm-mirror/clang/blob/f3b7928366f63b51ffc97e74f8afcff497c57e8d/include/clang/ASTMatchers/ASTMatchersMacros.h#L28
If someone could tell me whether this is a limitation to Clang's ASTMatcher API or not I'd be very grateful!
Never mind, I've found the answer by looking at the source of isExpansionInMainFile:
AST_POLYMORPHIC_MATCHER(isExpansionInMainFile,
AST_POLYMORPHIC_SUPPORTED_TYPES(Decl, Stmt, TypeLoc)) {
auto &SourceManager = Finder->getASTContext().getSourceManager();
return SourceManager.isInMainFile(
SourceManager.getExpansionLoc(Node.getBeginLoc()));
}
Turns out I missed the getASTContext in MatchFinder, which holds on to the source manager.
I'm using CentOS 6.6 (64-bit) and RH 1.10.2
I have a waveform that requires a FRONTEND::TUNER device that is of type RX_DIGITIZER. I also have a 1.10.2 based device that is a RX_DIGITIZER_CHANNELIZER. This device has all the functionality that the waveform needs, but the waveform will not use it because of the different tuner type.
I see that it is not picked because FrontendTunerDevice<TunerStatusStructType>::allocateCapacity() (in fe_tuner_device.cpp) that my device inherits looks for an exact match on tuner_type.
I'm not seeing any elegant ways around this. Here are the two not so elegant ways I can see around it.
I can either completely override allocateCapacity and duplicate 95% of its logic, but explicitly accept both tuner types.
Or I can override allocateCapacity and modify the capabilities before passing to the superclass method. In pseudo-code:
CORBA::Boolean MyDevice::allocateCapacity(const CF::Properties & capacities)
{
if ( capacities ask for RX_DITIGIZER ) {
CF::Properties caps = capacities;
change type to RX_DITIGIZER_CHANNELIZER
return super::allocateCapacity(caps);
} else {
return super::allocateCapacity(capacities);
}
}
Is there a better way?
The FrontEnd interfaces specification as outlined in Appendix E of the REDHAWK User Manual is a guide and has been known to be interpreted in different ways by REDHAWK device developers. In your case, the simplest solution would be to change the allocation in your waveform to an RX_DIGITIZER_CHANNELIZER and connect a listener to the device, assuming the device has the ability to output wideband data (RX_DIGITIZER). Otherwise, your suggested approach is correct while keeping in mind that the device must perform the appropriate bookkeeping should a user allocated DDCs against the CHANNELIZER portion of this device.
For more information, please refer to section E.2 on Frontend Tuner Types.
So as of Qt 5, QHttp is deprecated and we're all supposed to use QNetworkAccessManager now. Fine. But how do I make a request (HTTP or otherwise) from my multihomed machine without feeling like I'm playing roulette?
If there is no way, then what is a workaround? For my specific case right now, I just need to download a file via HTTP. But is there really no way to do this in a generic way with QtNetwork?
The quick workaround would be to use this in your project file
QT += http
It is still available in a separate module for compatibility.
If you are lucky enough that the desired interface is a separate physical (hardware) interface, you can do e.g. (web_view is a QWebView*):
QNetworkConfigurationManager config_manager;
QList<QNetworkConfiguration> configs = config_manager.allConfigurations();
bool found_interface = false;
QString desired_interface_name("eth1");
foreach (const QNetworkConfiguration &config, configs) {
if (config.name() == desired_interface_name) {
found_interface = true;
QNetworkAccessManager *network_access_manager = new QNetworkAccessManager;
network_access_manager->setConfiguration(config);
web_view->page()->setNetworkAccessManager(network_access_manager);
break;
}
}
if (!found_interface) {
//we failed to find the interface!
}
Again, this will not work if the IP is bound to a virtual interface part of one physical interface (e.g. eth1:1, eth1:2, etc). I am still looking for a solution for that case.