Syslinux - Jul 2015 - [PATCH] Updated udp.c to use real client ip and subnetmask values if on local subnet

>>>
 
 Jeff,
 Patrick: Could you try my code from my github repo branch
 efi-multinic?? It's derived from
 Patrick's code and I finally see good
 responses with a VMware VM's e1000e NIC
 (never saw ANYTHING good from
 it until
 now).
 
 git://github.com/geneC/syslinux.git
 https://github.com/geneC/syslinux.git
 
 -- 
 -Gene
 <<<<

I've seen your code.
Your first patch considered Pxebc, UDPv4Sb and  TCPv4Sb are created under the
same
handle but now we know this is not the case.
Your new patch now considers UDPv4Sb and TCPv4Sb are created under the same 
handle thing that we really do not know if is always true or not. 

My patch looks slower than yours because it parses the handles on every attempt
of binding
but it does not make any assumptions about the handles owning SB protocols. I
consider this
approach much safer.
About the speed of my patch; I do not think that matters compared to the time of
the smallest
transfer associated to the created child...
If you are really bothered by parsing the handles every time then we should save
both;
the associated UDPv4Sb and TCPv4Sb handles considering they might be different.

Best,
Patrick

On Mon, Jul 20, 2015 at 5:28 PM, Patrick Masotta <masottaus at yahoo.com>
wrote:
>>>>
>
>  Jeff,
>  Patrick: Could you try my code from my github repo branch
>  efi-multinic?  It's derived from
>  Patrick's code and I finally see good
>  responses with a VMware VM's e1000e NIC
>  (never saw ANYTHING good from
>  it until
>  now).
>
>  git://github.com/geneC/syslinux.git
>  https://github.com/geneC/syslinux.git
>
>  --
>  -Gene
>  <<<<
>
> I've seen your code.
> Your first patch considered Pxebc, UDPv4Sb and  TCPv4Sb are created under
the same
> handle but now we know this is not the case.
> Your new patch now considers UDPv4Sb and TCPv4Sb are created under the same
> handle thing that we really do not know if is always true or not.
Not strictly.  Look closer.
> My patch looks slower than yours because it parses the handles on every
attempt of binding
> but it does not make any assumptions about the handles owning SB protocols.
I consider this
> approach much safer.
The sole assumption I make is that we're most likely to repeatedly
want the same handle.
> About the speed of my patch; I do not think that matters compared to the
time of the smallest
> transfer associated to the created child...
> If you are really bothered by parsing the handles every time then we should
save both;
> the associated UDPv4Sb and TCPv4Sb handles considering they might be
different.
No need.

Pseudo code:  Using the most recently used handle (the one holding
Pxebc by default), attempt to create a service binding.  If
unsuccessful, hunt for a handle that provides the target service
binding and matches the MAC address.


Best case, it's 1 binding attempt.  Worst case it's about N+1.

-- 
-Gene

>>>
 Pseudo code:? Using the most recently used handle (the one holding
 Pxebc by default), attempt to create a service binding.? If unsuccessful, 
 hunt for a handle that provides the target service
 binding and matches the MAC address.
 
 Best case, it's 1 binding attempt.? Worst case it's about N+1.
 
 -- 
 -Gene
<<<

I see; on fail you fall back getting all handles again by "bguid".
This approach would have no benefit if there are consecutive alternative 
binding (UDP/TCP) but that's unlikely to happen.

Best,
Patrick