On Sat, Jun 03, 2017 at 02:28:46AM +0000, Darrell Ball wrote:
> 
> 
> On 6/2/17, 4:32 PM, "[email protected] on behalf of Ben Pfaff" 
> <[email protected] on behalf of [email protected]> wrote:
> 
>     On Tue, May 30, 2017 at 10:49:27AM -0700, Darrell Ball wrote:
>     > This patch introduces NAT support for the userspace datapath.
>     > Most conntrack module changes are in this patch, with the
>     > exception of icmp related handling and recent orig tuple
>     > support.
>     > 
>     > The per packet scope of lookups for NAT and un_NAT is at
>     > the bucket level rather than global. One hash table is
>     > introduced to support create/delete handling. The create/delete
>     > events may be further optimized, if the need becomes clear.
>     > 
>     > Some NAT options with limited utility (persistent, random) are
>     > not supported yet, but will be supported in a later patch.
>     > 
>     > Signed-off-by: Darrell Ball <[email protected]>
>     > Acked-by: Flavio Leitner <[email protected]>
>     > Acked-by: Daniele Di Proietto <[email protected]>
>     
>     nat_range_hash() seems to have some problems: it has multiple statements
>     like this:
>         memcpy(&port, &conn->nat_info->min_port, sizeof port);
>     where the destination is a 4-byte object but the source is a 2-byte
>     object.  I changed 'port' from uint32_t to uint16_t, which I think
>     fixes the problem.
> 
> Thank you Ben
> 
> About uint32_t vs uint16_t:
> Sorry for the confusion - this should have had comments.
> In this case, uint32_t was intentional because I want to include both min_port
> and the following max_port in the hash.
> In the other 2 cases, I also want 4 bytes because there is a 4 byte union.

Oh, my mistake, sorry about that.  Anyway it will be good to get this
clarified, thanks.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to