I am trying to find out whether the Linux net_device_ops are serialized by the caller or that the driver implementing these ops must take care of the serialization (or than they can be called concurrently).
For example can for the same driver instance the ndo_start_xmit called again (e.g at a different CPU) before the driver has finished the current ndo_start_xmit call?
I searched how other net_device drivers are doing this but it looks like that they assume that ndo_start_xmit serialization is done by the caller (please correct me if I am wrong).
However I also searched whether the caller uses and spinlock or another lock mechanism, but I could not find one. If such a (caller) lock mechanism exist please point me to the code that does this.
In most cases it is the caller who should take care of serialisation, and net_device_ops are typically implemented as lock-unaware. However, it is possible that you still may find some sort of locking inside net_device_ops done by some drivers for their internal purposes - it's just possible, for instance, that a driver needs to access its own global data/counters within an either callback.
ndo_start_xmit, indeed, might be a quite eloquent example to observe where locking may reside. In this case, indeed, a lock is held by the upper-layer caller. You may find it helpful to take a look at the corresponding place within dev_queue_xmit() kernel function. As you see, lock is acquired there prior calling dev_hard_start_xmit() function which in turn calls xmit_one() function. It's easy to track it further, namely, you may observe netdev_start_xmit() code calling ndo_start_xmit provided by the driver.
Also, it might be worth reading Linux Device Drivers, 3rd Edition book, namely, the paragraph 17.5.1 in the section 17.5. I hope you find it helpful.