<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">There are multiple elements to this since one would need l2 and l3 access.</div><div class="gmail_default" style="font-family:times new roman,serif">
<br></div><div class="gmail_default" style="font-family:times new roman,serif">On the l2 level you would use the MAC address for packets and then format the content of the frames yourself. This would allow support of an arbitrary ethernet protocol. Applications would have to be able to set the MAC addresses where they would like to receive traffic (multiple in order to support broadcast and multicast addresses).</div>
<div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">On the l3 level the IP address would be used as the address and supportive functions are available (like NIC calculation / verification of checksums and the remainder of the typically provided offload for regular NICs).</div>
<div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">The flow steering API kind of covers both of these levels to some extend but it is something to the side.</div>
<div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">The fundmantal idea is that these protocols would allow the use of the Fabric API to generate IP datagrams and thereby native IP format traffic can be supported. This allows writing of userspace frabric communication layers based on IP that would work with commodity hardware.</div>
<div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">For us also the effect is that we would like to create a user space IP stack and use the fabric API to communicate directly with IP based servers and services that may just operate with a standard OS IP stack. The fabric API then works as an way to bypass the operating system. </div>
<div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">This is solution that currently works very well for us. We do both IP based and IB based communication through the IBverbs/RDMA apis.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 18, 2014 at 7:45 PM, Hefty, Sean <span dir="ltr"><<a href="mailto:sean.hefty@intel.com" target="_blank">sean.hefty@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Christoph,<br>
<br>
In the last meeting, you mentioned adding an Ethernet protocol option.  That's easy enough to add, but can you provide some lower-level details on what you're looking for (or confirm the items below)?<br>
<br>
Would an app use MAC addresses directly?  (Add an FI_MAC fi_addr_format.)<br>
<br>
Would input buffers into data transfer operations be the Ethernet frame data?  (I.e. the input buffers would NOT include the MAC header.)<br>
<br>
Can you think of any other changes that would be needed to fully support data transfers over a raw Ethernet endpoint?<br>
<span class="HOEnZb"><font color="#888888"><br>
- Sean<br>
</font></span></blockquote></div><br></div>